Introducing organizational controls and SSO for Render Enterprise. Learn more

テレビで素敵なサイトが紹介されていたのでアクセスしてみたら、なかなかレスポンスが返ってこなかったりステータスコード503になったりすることってありますよね。 テレビで紹介されたことで多くの人がサイトにアクセスした結果、そのサービスのキャパシティを超えてしまったわけです。 どうなるとキャパシティを超えるのでしょうか? また、いつからレスポンスが遅くなるのでしょう。 効果的にリクエストをさばくにはどうしたらいいのでしょう。 Photo by Roman Arkhipov on Unsplash 待ち行列理論を使って理想的なモデルからこれらを考えてみたいと思います。 待ち行列理論はコンピュータサイエンスをやってきた人はみんな触れたことがあるとは思いますが、大石の場合はそれが何十年も(!)前のことなのであらためて思い出してみました。 モデル Railsでサービスを提供するとき、rackサーバとして
WebROaRはRuby製のオープンソース・ソフトウェア。Railsアプリケーションを公開する際、通常何らかのHTTPサーバと組み合わせて利用する。かつてはApache + Mongrelが人気で、最近ではApache + Passengerまたはnginx + Passengerという組み合わせが人気だ。 高パフォーマンスが売りのデプロイサーバ そんな中、またしても新しいデプロイサーバが登場した。管理画面付きのすごいやつ、それがWebROaRだ。パフォーマンスの高さを誇っており、使い勝手も良い。まだ開発途中とは思われるが今後に期待のできるとても興味深いソフトウェアだ。 対象はUbuntu/Debian/Mac OSX/CentOSとなっている。今のところWindowsはサポートされていない。インストールはRubyGemを使って簡単に完了する。WebROaRを立ち上げると専用の管理アプリケ
■ [ruby] 大規模Railsサイトのための新しいHTTPサーバ、Unicorn githubの中の人が、ブログで「Unicorn使い始めて一ヶ月くらい経つけどいい感じだよ」と書いています。 適当に要点だけ拾ってみました。 Unicornって何よ? UnicornはRubyのためのHTTPサーバ。MongrelやThinのようなものだけど、全く違う設計と思想を持っている ありがちな構成 [mongrel] [mongrel] .. [nginx] -> [haproxy] -> [mongrel] [mongrel] .. [mongrel] [mongrel] .. 問題点: あるactionの処理に60秒以上かかったとき、Mongrelが当該スレッドをkillしようとして固まることがある メモリが一定量を超えたときMongrelを再起動するのが遅い。 デプロイ時に9個のmongre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く