Apacheチューニング
2. チューニング • KeepAliveの設定 • コンテンツの圧縮転送 • 不要モジュールの削除 • シンボリックリンク先の参照許可 • TimeOutの設定 • DNS問い合わせの無効 • .htaccessの無効化 • Prefork MPMのチューニング • Worker MPMのチューニング 3. KeepAliveの設定 ディレクティブ 値 説明 KeepAlive On 同一クライアントに対し コネクションを使い回す MaxKeepAliveRequests 1ページあたりの平均 的なコンテンツ数 + α 1つのKeepAliveで受け付け るリクエスト数 KeepAliveTimeout 1ページ当たりの平均 的な転送時間＋α クライアントからのリクエ ストがなくてもKeepAliveを 維持する秒数 5. 不要モジュールの削除 デフォルトでは多くの拡張モジュー ルが組み
ApacheでCGIを使う場合にpreforkを使った方が良い状況とそのチューニングについて - 人間とウェブの未来
かなり今更感の漂う内容ではありますが、意外と情報が分散していたり、Apache2.4系を考慮した場合に足りていない内容があったのでこのエントリで一度まとめてみようと思います。 CGIを使うようなシステムでそれなりにアクセスが集中するサーバ、例えば日々のピーク時のApacheのbusyワーカー数が1000になるようなサーバで、かつ、それを処理可能なマシンスペックのサーバであることを前提にしています。 ApacheのMPMとCGI実行アーキテクチャの復習 ApacheでCGIを使う場合には、MPMとCGI実行アーキテクチャの組み合わせは大きく分けて以下の2つに分ける事ができます。 worker(event) + mod_cgid prefork + mod_cgi Apacheの2.4系から特にworker(event) + mod_cgidのモデルが推奨されているようです。また、2.4系では
最新（2013/12/26）のmod_mrubyとngx_mrubyのパフォーマンス
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 論文の執筆や発表の準備で最新のmrubyに追随できていなかったのですが、ようやくmod_mrubyとngx_mrubyを最新版のmrubyに対応させました。対応した項目は以下となります。これでmrubyの最新版でも動くようになりました。 mrb_stateが持っていたirepテーブルの削除に対応（バイトコードのGC化） symbol関連のAPI変更に対応 ARENAの持ち方を修正 パフォーマンス比較をするには良いタイミングなので、最新版のmod_mrubyとngx_mrubyのパフォーマンスを計測しました。 最新のパフォーマンス比較 計測方法はいつも通りシンプルなものなので、「この条件だと大体こういう差がでる」という意味での参考情報として見て
Why is FastCGI /w Nginx so much faster than Apache /w mod_php? - ESchrade - Kevin Schroeder
ESchrade – Kevin Schroeder Developer, author, musician, global domination theoretician I have a new post on using Jetty with PHP-FPM that, if you think this is interesting, you should check that one out. (this post has a sister post on Apache’s event MPM compared to Nginx) I was originally going to write a blog post about why NginX with FastCGI was faster than Apache with mod_php. I had heard a w
Apacheのmod_cacheを利用して静的コンテンツをキャッシュさせた話（追記あり）
Fusic 平田です。 前のエントリの延長のようなそうでもない話です。 あらすじ ある日「サーバがレスポンスをろくに返さない」と連絡があり、すわ障害発生かとおもむろにsshクライアントを立ち上げ、接続。 この時点でよくあるのは サーバがハングしていたりして接続できない なんとか繋がるもののすごく重い・ロードアベレージが鬼のように高い その他障害などでエラーが発生しているとかディスク障害が起きてるとかblog書いてる場合じゃない事態とか といったあたり（書いてる場合じゃない事態はそうそう起きません）なのですが。 普通にssh接続できるし、dstatで眺めてもCPUなりメモリなりで刺さってるわけでもなし。 はて。。。と思いつつ とかやってみると、滝のように流れまくるアクセスログ。 「どうしてこうなった」はさておき、とにかく対応せないかんという話で。 前のエントリの流れを汲むなら「よしvarni
過負荷をかわす Apache の設定 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
Apache チューニング Tips | Carpe Diem
先日、Web サーバ勉強会 #2 が開かれました。内容は、Apache のチューニングということで、参加したかったのですが、他の予定があって参加できませんでした。 そこで、僕が個人的に行っている Apache のチューニングを紹介したいと思います。最初、スライドで作成しようかと思ったのですが、ブログにまとめたほうがよさそうなのでブログにまとめていきます。 まず、大前提として Apache をチューニングするうえで、大事なことはその Apache が提供する Web サービスの種類のよって大きくチューニングする内容が異なるということです。例えば、動画・写真共有サービスと株価情報のサービスを比較すると、当然のことながら大きくサービスの内容が異なりますし、HTTP レベルでみるとクライアントからのリクエスト数、データサイズ、などがかなり違ってきます。 ですので、まずは自分が扱っているウェブサービ
フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - （ひ）メモ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://robertbasic.com/blog/benchmarking-pages-behind-a-login-with-ab/