多分Nginxでゴリゴリやっている人ならm9(^Д^)ﾌﾟｷﾞｬｰだろうけど、メモっておく。 サーバサイドでSSL処理をする際に少しでもCPU処理を軽くする＋レイテンシを下げたい目的で ssl_session_cache shared:SSL:128m; ssl_session_timeout 300m;的な設定を入れた所、負荷が高い時間帯に [alert] 14099#0: *1627571 could not allocate new session in SSL session shared cache "SSL" while SSL handshaking, client:〜省略〜というログが出た。ソースコードをほげほげ読んでみると ngx_event_openssl.cのngx_ssl_new_session で記述されている処理でおそらく キャッシュ領域に書き込もうとする 溢れ
ISUCON 3 の予選に出場してきました。そして敗退しました。 全然全然全然全然駄目で駄目な感じでした。 スコアが上がらねえのなんのってもう惨敗でした。 やったことを時系列順に書くとこんな感じ。ちなみに言語はPerlです。 とりあえずベンチ走らせてみる mysqld の CPU 使用率がトチ狂っているので、真っ先にここを直した方が良いと指摘 インデックスの張り忘れでは？ という事で EXPLAIN で確認しようぜ、というのを@__papix__さんに任せる ついでに my.cnf 弄ってスロークエリログを吐くようにする mysqld をリスタートする mysqld リスタートすると、プロセス上では起動できてるしコンソールでもログイン出来るんだけど、アプリ側が "MySQL Server has gone." とかエラー吐いて mysqld を認識しなくなる 誰かが言い始めた「しかたねえか
ツチノコブログの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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
