サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
qiita.com/Oakbow
Webアプリケションのパフォーマンスに多く影響してしまう N+1 問題。 正直製品レベルのアプリケーションだと基本的にないのが当たり前だと思っていますが、うっかりミスで残っちゃったりするのも事実。 なので N+1 問題を教えてくれるgem、Bullet を使っている人は多いと思います。 最近では Rails では API サーバのみを作り、フロントエンドは JS フレームワークやスマホアプリで実装というケースが増えてきました。 こういったプロジェクトでは Rails で画面をまったく作らないので、画面があること前提の開発支援系 gem を使えなくて困ったりします。 そこで bullet に関してはテスト環境で動作させるようにしました。 bullet のテスト環境設定 とっても簡単です。 config.after_initialize do Bullet.enable = true Bull
開発時にはちょくちょくデータの中身を見たり書き換えたりしたいもの。 CUI の方が好きって方も多いと思いますが、私は GUI で閲覧・操作したいと思うタイプです。 MySQL を使っている時は MySQL Workbench を使っていたんですが、PostgreSQL の場合ははてどうしようと考え、せっかくなので RubyMine を使うことにしました。 データベースに接続する機能は以前からありましたが、今までは使ったことなかったんですよね。 Heroku Postgres の接続文字列 Heroku Postgres は heroku 自らが提供するアドオンです。 実体は AWS EC2 上に存在しているため、これ単体を利用することも可能になっています(と聞きました)。 今回は普通にアドオンとして使用していますが、これに対してローカルから外部接続を行うことになります。 外部接続に必要なの
最初に言ってしまいますと、Qiita の以下の記事を(ほぼ丸々そのまま)参考にさせていただいて実装を行っています。 RailsのセッションストアとしてRedisを使う(Mac/EC2:AmazonLinux) | Qiita 若干自分好みに環境設定を変えているのと、本番環境が AWS と heroku で違うだけです。 元ネタの記事をご覧になっていただいた方が話が早いかもしれません。 この頃評判のいい Redis をセッションの保存先として使用するよう設定してみました。 Rails のセッションの保存先はデフォルトでは Cookie ですが、下のような話もあるので検討の結果 Redis にしてみた感じです。 Rails SessionにCookieStore使った時の問題点 | OAuth.jp 一応調査するにあたっていろいろ調べたのですが、こういうサイトの性能比較を見ると結構すごいな、と
注意(2021年6月追記) この記事は99%の人には何の参考にもなりません。 経験上はアプリケーションに特に問題がないのに Appilication Error が発生し、再起動で解決するということは稀に起こります。 少なくともここ数年は私の環境では起きていませんが、執筆時点(2013年3月)の heroku では稀に発生していました。 ずっと安定稼働していて特に思い当たる原因がない場合の対処法であって、Application Error が起きた時にいつでも通用する対処法ではありません。 このエラーが発生している場合は9割9分アプリケーションに問題があるので、きちんとエラーログを見て原因を特定してください。 heroku で運用を行っていると、原因不明の ApplicationError が発生することがあります。 30秒ルール以外で発生する場合、経験上はエラーコード H10 が発生して
ダウンロードファイルに日本語を使用する場合、IE だと文字化けする現象に悩まされることが多いと思います。 これは、IE がダウンロードファイル名に SJIS(WIndows-31J)を基本的に要求するためです。 (正確には、OS の言語設定のデフォルトコードページ、だったかも。日本語だと CP932 ですが、他の言語だとまた違うと思います) なので多くの方は IE 向けに SJIS に文字エンコーディング変換を行うか、URL エンコードしていると思います。 MS の KB にも下記のように言及されています。 http://support.microsoft.com/kb/436616 IE9 からはダウンロードファイル名を UTF-8 として扱う(SJIS でも正常に扱える)ので、この問題に頭を悩ませる機会は今後減りそうですね。 一方、表題の Excel は基本的に SJIS オンリーで、
結論 どちらか好きな方読め。 heroku-deflater | github heroku_rails_deflate | github 読んだら好きな方の gem を入れろ。 -糸冬- 追加でやった方が良いこと heroku がオリジンサーバの場合、assets 内のリソースファイルのリクエストは可能な限り減らしたいところです。 そのためにブラウザのキャッシュを利用しましょう。 こちらも参照してみてください。 herokuでブラウザのキャッシュを利用する | Qiita 周辺事情 Web サービスがブラウザに返却するリソースは、HTML、CSS、JS、そして画像ファイルが大勢を占めます。 HTML,CSS,JS はご存知のようにテキストデータで、こいつを圧縮して送信できるとレスポンスタイムを削減することが出来ます。 heroku のようにサーバが遠い場合は特にその恩恵にあずかることが出
独立して読んでいただける様書いていますが、S3+CloudFrontでWebフォントを利用する(FireFox対応)の続編的位置づけです。 heroku で運用していると CSS、JS、画像、WebフォントなどをCDNで配信したくなるので、そのやり方をまとめました。 実は heroku の仕様変更で構成を変えざるを得なかったためにやったんですが、結果的にいい形にまとまったと思います。 大いに参考にしたサイトがこちら。 CloudFront CDN with Rails on Heroku こちらを読めばこの記事は読まなくてもいいかも。 Asset Sync をやめる。 Asset Sync は、heroku へのデプロイ時に実行される rake assets:precompile の際に、S3 などの外部ストレージに assets の中身をコピーしてくれる gem です。 元から使っていな
結論からいうと、以下の3点で対応可能です。 1.S3 のバケットに CORS の設定を行う。 S3 Management Console で対象バケットを開き、右上の Properties ボタンを押します。 項目がいくつか現れますが、その中の Permissions を展開して、Edit(Add) CORS Configuration ボタンを押し、表示される CORS Configuration Editor に以下のように入力して saveします。 AllowedOrigin は Web フォントを使用するリクエスト元となるドメインです。 必要な数だけ列挙します。 <?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <COR
こんな風になってるはず。 どのページでも共通に読み込みたい JavaScript が以下の二つだった場合。 app/assets/javascripts/hogehoge/fugafuga.js app/assets/javascripts/areare/korekore.js.erb //= require_tree . を削除してこんな風に修正します。
ルートドメイン(Apex ドメイン)は使えない Heroku でアプリケーションを作成すると、漏れなく newapp.herokuapp.com というドメインを使用することができます。 独自のドメインを割り当てたい場合は、heroku の設定で、Domains にドメインを登録してあげると良いです。 ただし、ここで通常使えるのはサブドメインがついているタイプのもの。 ルートドメインは(そのままでは)使用できません。 www.jobhub.jp というドメインはいいけど、jobhub.jp はダメなんです。 http://jobhub.jp ってURLで運営できないってことですね。 公式でも、ルートドメインを避けるよう解説されています。 Avoiding Naked Domains and DNS A-records ANAME を利用してルートドメインを使う でも、どうしてもルートドメイ
Web サーバやアプリケーションサーバは、リクエスト数やメモリ使用量がある閾値を超えたらプロセスの再起動を行う仕組みが用意されています。 Apache にも IIS にもそのための設定項目が用意されていて、この仕組みを一般にリサイクルと呼ぶようです。 UA からのリクエストをさばくワーカープロセスが疲弊せず、パフォーマンスを維持するための仕組みですね。 Ruby で人気のアプリケーションサーバである Unicorn ですが、残念ながらこのリサイクルの機能を持っていません。 どうにかできないかなーと思って調べていたら、この短所を補完する Gem がリリースされていました。 Unicorn Worker Killer | github そのまんまですね。 この Gem でできるのは、以下のようなリサイクルです。 ・一定のリクエスト数を超えたらランダムで再起動する(上限に達したら必ず再起動)。
heroku でWebサービスを運営している時って、監視系はみなさんどうしてますか? おそらく定番アドオンである New Relic と Air Brake を使用していると思うのですが、これらでは heroku で発生するタイムアウトを検知できません。 30秒以内に応答返せなかったらってアレですね。 考えてみれば heroku の Error Code12 は例外がスローされてるわけじゃないので、Air Brake 対象外。 タイムアウト処理しているのは WebDyno じゃなくて heroku/router なので New Relic で捕捉できない、ってことのようで。 どうしようかなといろいろ調べましたが、結局 Papertrail の検索結果送信機能を使うことにしました。 Papertrail を使う Papertrail は heroku のログ取り扱いアドオンです。 Logly
update 記事中ではCarrierWaveのキャッシュ機能を使用できないと記載していますが、v0.10.0よりキャッシュの保存先をS3などに指定できるようになっているようです。 詳しくは以下の記事などを参照してください。 CarrierwaveでS3にアップロードさせるとき、キャッシュもS3に置く - Qiita 現時点でキャッシュストレージをS3に変更してテストをしていませんが、パフォーマンス上の問題が発生しないようであれば、こちらを選択するのもありかなと思います。 ファイル名長さの制限はherokuではなくS3(ファイルパス含め1000バイト?)のものになり、かなり緩和されることになります。 Ruby/on Rails には CarrierWave というファイルアップロード用の Gem があります。 人気の Gem なので使っている方も多いと思いますが、同じくRailsの実行環境
このページを最初にブックマークしてみませんか?
『@Oakbowのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く