3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
パフォーマンスグラフの見方とか - だるろぐ
（追記：このエントリは自力ではありません） CloudForecast というリソース管理ツールがあります。 色々見られるのはいいんですが、[よく分からん|知らん|勘違いしている]項目ばかりなので解説のようなものを。 Traffic Throughput 転送量。 Inbound 外部から受けたリクエスト。webサーバやproxyサーバの場合、主に、というか基本的にユーザからのリクエスト。 Outbound 外部へ返すレスポンス。 なお、In/Out両方とも、単純に サーバ <*> ユーザ の間でやりとりしているデータ量より多い量がグラフで見える。 例えばInboundの場合、リクエスト受けて、バックエンドにproxyして結果を受け取ってユーザに返す、とかするから。 Basic system psとかstatとかで見られるアレ。 Load Average コア数を考慮して見る。値が1でも、
YAPC::Asia::Tokyo 2009行ってきた - だるろぐ
YAPC初参加。メモ書き。 一日目（9/10） Tokuhiro Matsuno (tokuhirom) - PSGI - Perl Server Gateway Interface pythonのWSGIみたいなことをしよう、ということでtokuhiromさんとmiyagawaさんがWSGIのperl版を作ろうとしてる話。tokuhiromさんのブログでも以前から触れている。 PSGIは仕様、PLACKは実装ということで、PSGIが何を目指すかの説明とPLACKの紹介など。 アプリを動かすのにmodperl fastcgi apache1/2とか沢山あって、WAFごとにそれに対応するコードを書くのが無駄だから、その辺の規約を統一しようぜ、というのがPSGI。それを実装したのがPLACK。railsのRackみたいなもの。 既にHTTP:Engineというものがあるが、これはreponse
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
