You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
2017-08-15 追記 Googleの「Capistrano」検索順位で上位にあるためか、いまだにこの記事がたびたびブクマされるんですが、3年前の情報ですし、執筆者はRubyを専門としたプログラマーではないのでその点ご注意ください。(追記ここまで) いろいろエントリーを上げながら苦しんでいたCapistranoだが、ようやっとそこそこ落ち着いてきた気がするのでそろそろ完結編といく。Capistranoの基本とかはすでにこちらのエントリーで書いたので、今回は各設定ファイルの書き方とか、その他ハマったポイントを中心に。 今回作成したファイル 以下4ファイルを作成した。 Capfile config/deploy.rb config/deploy/staging.rb lib/capistrano/tasks/unicorn.cap 基本的にCapistranoを使う場合「必須」なのは上2つ
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
rails_deploy.md Rails デプロイ Ruby on Railsの欠点と言えば,デプロイ作業が若干面倒くさいところかもしれません. コンテンツを公開ディレクトリに設置してパーミッションを設定するだけでは動作しません. ここではRailsのデプロイ方法について簡単に紹介します. Rackライブラリ RackはRuby系のWebサーバやWebアプリケーションフレームワークで主に使われています. Rackは,WebサーバとWebアプリケーションをつなぐインターフェースの役割を果たすライブラリです. サーバ,アプリ共にRackで共通化してしまえば,どちらかを差し替えても問題なく動作します. つまり,Rackに対応していればどんなサーバでも,どんなフレームワークでも組み合わせることができるというわけです. RailsもこのRackを使用しているので,Rackに対応したサーバを使わない
{{toc_here}} はじめに Unicornは、Unix系システムで動作するRackアプリケーション用サーバ。接続時間が短いことを前提とした設計となっている。 - http://unicorn.bogomips.org/ preforkモデル Unicornはpreforkモデルを採用している。 Reverse Proxy └TCP Socket[0.0.0.0:8080] > Unicorn(Master) ├(fork)─Worker[0] < TCP Socket[0.0.0.0:8080] ├(fork)─Worker[1] < TCP Socket[0.0.0.0:8080] ┆ └(fork)─Worker[N-1] < TCP Socket[0.0.0.0:8080] マスタプロセスからforkした複数のワーカープロセスがあり、クライアントからのリクエストを
本記事は英語版ブログで公開された記事の翻訳版です。 2013年7月に、米国テキサス州オースティンで開催されたLonestar Ruby Conferenceで、Rubyによるアプリケーションサーバーについてお話させていただきました。その中でいくつかのRubyアプリケーションサーバーのパフォーマンスや、さまざまな状況における挙動の違いを比較しました。この記事では、講演準備として行ったリサーチの中で分かったことをかいつまんでご紹介します。 実際のカンファレンスの録画をご覧になりたい方は、Confreaksで公開されていますのでそちらをご参照ください。テストに使用した簡単な自作アプリケーションはGitHubに、講演スライドはSlideshareにそれぞれ公開しています。 このリサーチは、Passenger 4のパフォーマンス評価以外すべて2013年7月に行ったものなので、情報が多少古くなっている
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました!びっくり!\(^o^)/ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く