Thread Pools in NGINX Boost Performance 9x!
It’s well known that NGINX uses an asynchronous, event‑driven approach to handling connections. This means that instead of creating another dedicated process or thread for each request (like servers with a traditional architecture), it handles multiple connections and requests in one worker process. To achieve this, NGINX works with sockets in a non‑blocking mode and uses efficient methods such as
nginxのパラメータチューニングとh2o - Qiita
(追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
nginx で Too many open files エラーに対処する
nginx では1プロセスで多くのアクセスを捌くので、アクセス数が増えるとToo many open filesエラーが発生することがあります。 ここでは対処法と調べた内容を残しておきます。 1. fs.file-max の確認 まず fs.file-max の値を確認しておきます。fs.file-max は、システム全体でのファイルディスクリプタの上限数となっており、この値以上のファイルディスクリプタは確保することができません。 現在設定されている値は以下で確認できます。 $ cat /proc/sys/fs/file-max 167488 通常は上記の値で問題無いと思いますが、もしこの値が不足しているようなら設定値を更新します。 $ sudo -s # echo 320000 > /proc/sys/fs/file-max # cat /proc/sys/fs/file-max 320
Tuning nginx worker_process to obtain 100k hits per min
We have a server that is serving one html file. Right now the server has 2 CPUs and 2GB of ram. From blitz.io, we are getting about 12k connections per minute and anywhere from 200 timeouts in that 60 seconds with 250 concurrent connections each second. worker_processes 2; events { worker_connections 1024; } If I increase the timeout, the response time starts creeping up beyond a second. What else
Optimising NginX, Node.JS and networking for heavy workloads
9 Min Read Optimising NginX, Node.JS and networking for heavy workloads Used in conjunction, NginX and Node.JS are the perfect partnership for high-throughput web applications. They’re both built using event-driven design principles and are able to scale to levels far beyond the classic C10K limitations afflicting standard web servers such as Apache. Out-of-the-box configuration will get you prett
isucon2 を開催しました。あるいは、優勝組の5倍のスコアを出す方法 - blog.nomadscafe.jp
去年の第一回では、次の日に3時間の昼寝をしていたようですが、今年は開催中に体調を崩してしまい、参加者の皆様がハックをしている最中にクッションで横になっているという状態になってしました。セットアップの不手際と合わせて申し訳ないと思っています。また家の事情的なこともあり、準備段階であまり協力できなかった中、ibuchoさん、941さん、やぶたさん、tagomoris、sugyanには感謝しております。そして参加者、協力して下さった方みなさまに感謝しております livedoor Techブログ : #isucon2 リアルタイムフォトレポート 更新終了 livedoor Techブログ : #isucon2 参加者・関連エントリまとめ tagomoris/isucon2 - GitHub ISUCON2では課題となったチケット販売サイトのアプリケーションの作成はsugyanが行い、ベンチマークツ
app serverがリクエストの処理にかかった時間をログに記録する
Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、本件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数
#isucon で学ぶWebアプリの高速化の話 : As Sloth As Possible
あるいは、お遊びチーム2号は一体何をしていたのかについて。 ISUCONという大変白熱した楽しいお祭を開催するにあたって、その前夜祭的な環境試験のためのチューニング祭が社内の有志数名で行われていて、そのときに色々学んだことをおまけとして書いておきます。 ISUCONて何？ 下記参照。 なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 【締め切りました】Webアプリケーション高速化バトル、#isucon 詳細と参加者募集開始 ISUCON に参加してきました #isucon に参加してきました＆isuconツールを試してみました #isucon で優勝してきました isuconに参加してきた＆チーム「いんふらえんじにあー」の戦略など isuconお遊びチーム（事前社内β組）の設定あれこれ #isucon で優勝させてもらってきました #isucon に参加して
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
軽量高速Webサーバのnginxで静的コンテンツ配信とキャッシュコントロール
nginxとは？ nginxはロシアで開発されている軽量で高速なWebサーバです。 現在シェアは 7% 近くあるようです。もちろんApacheに比べれば少ないですが、Apache 55%、IIS 25%, nginx 7%で3番目に使われているWebサーバになります。 昔は、Pound+Lighttpd+Apacheの組み合わせをよく使っていましたが、ここ数年はnginx+Apacheとかになりました。 主に、静的コンテンツをnginxが受け持ち、PHPなどの動的コンテンツはApacheに渡す形になります。Railsを使う場合は、nginx+Unicornの組み合わせが多いです。 いまさらな感じもありますが、インフラ周りの見直しも含めて紹介したいと思います。 静的コンテンツをnginxに任せる nginx+Apacheの場合の設定は次のようになります。（nginxがport 80、Apac
How We Made GitHub Fast
EngineeringHow We Made GitHub FastNow that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we've made in order to bring… Now that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we’ve made in order to bring you a speedier, more scalable GitHub. In my f
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践nginx〜メルカリの場合〜