Nginxのworker_processesとworker_cpu_affinity | 設定やツールねた
Nginxの設定項目にworker_processesというものがある。Nginx本体のプロセス数を設定するもので、Debianの標準パッケージだと4が設定されている。 /etc/nginx/nginx.conf worker_processes 4; とくに変更する必要はないが、Nginxがシングルスレッドで動作するため、コア数に合わせて設定しておくのが標準的な運用である。 # grep processor /proc/cpuinfo |wc 2 6 28 この場合、コア数は2なので、 worker_processes 2; として運用する。 とはいえ、コア数が2の場合でworker_processesを4にしてプロセス数が多くても特別問題ないので通常は変える必要はないだろう。 プロセス数が多いほうがいいのは、写真を多く扱っていたり、コンテンツが多い場合である。コンテンツにおけるページ数
ApacheとNginxの性能比較でevent_mpmの本気を見た
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
高速WebサーバMighttpdのアーキテクチャ | IIJの技術 | インターネットイニシアティブ（IIJ）
IIJ-II技術研究所では、2009年の秋からMighttpd（mightyと読む）というWebサーバの開発を始め、オープンソースとして公開しています。この実装を通じて、マルチコアの性能を引き出しつつ、コードの簡潔性を保てるアーキテクチャにたどり着きました。ここでは、各アーキテクチャについて順を追って説明します。 ネイティブ・スレッド 伝統的なサーバは、スレッド・プログラミングという手法を用いています。このアーキテクチャでは、1つのコネクションを1つのプロセスかネイティブ・スレッドが処理します。 このアーキテクチャは、プロセスやネイティブ・スレッドを生成する方法で細分化できます。「プール」方式では、あらかじめ複数を起動しておきます。例としては、Apacheのpreforkというモードが挙げられます。「都度」方式では、コネクションを受け取るたびに生成します。このアーキテクチャの利点は、制御を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://mew.org/~kazu/material/2011-server.pdf
