All of Percona’s open-source software products, in one place, to download as much or as little as you need.
![MySQL Connection Timeouts](https://cdn-ak-scissors.b.st-hatena.com/image/square/b56e86e78d4cf20ae5da5f8f28fac0531d82e826/height=288;version=1;width=512/https%3A%2F%2Fwww.percona.com%2Fblog%2Fwp-content%2Fuploads%2F2020%2F05%2FBlog_SignUp.jpg)
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
A modern HTTP server running on somewhat recent hardware is capable of servicing a huge number of requests with very low latency. Here’s a plot showing requests per second vs. number of concurrent connections for the default index.html page included with nginx 1.0.14. With this particular hardware & software combination the server quickly reaches over 500,000 requests/sec and sustains that with gr
サーバ周りの勉強していると、たまにselectとかepollとか言葉が出てきて、理解できてなかったので調べてみた。 I/Oの多重化 例えばサーバ周りの実装を、特に何も考えずにやると、I/Oでブロッキングが発生し、一つのクライアントとしか通信できないということが起こります。これを解決するために fork threads I/Oの多重化 非同期I/O といった方法があります。 この中のI/Oの多重化を実装するためのシステムコールとして、select, poll, epoll, kqueueなどは実装されているようです。 少し調べてみると、次のような記述のような機能をそれぞれが実装するようです。 プログラムで複数のファイルディスクリプタを監視し、 一つ以上のファイルディスクリプタがある種の I/O 操作の 「ready (準備ができた)」状態 (例えば、読み込み可能になった状態) になるまで待つ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、1セッション1スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを1スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
先週末はThriftのスピード問題にはまり、ガンダム戦記にはまり、ほとんど外に出られませんでした。前回のエントリー(Thriftのスピードについて)の続きとなります。 やっぱりperlのクライアントライブラリに問題がありそう? 多くの有識者の方にアドバイスをいただき感無量でございます。前回のエントリーでは、perlライブラリ、pythonライブラリでThriftが異常なほどに遅いんじゃないか?といった内容でございました。当方のバグではないかと、おそるおそる前回のエントリーをポストしたのですが、tokuhiromさんがこの現象に関して調査と考察の結果を示してくれました(ThriftのPerl Clientが遅すぎる件について)。 クライアントが Pure Perl で書かれており、かつ実装に適当さが感じられ、「速そうには、みえないな。。。」と感じました。 Facebook 内で実際に使用され
今回はLinuxのネットワークチューニングの一部を書きます。 このチューニングはkernelのバージョンに(2.6.17以前が前提 )依存するので、やった方がいい場合とAutoチューニングでお任せの方がいい場合があるので注意が必要です。 また、チューニングの目的がはっきりした方がよいでしょう。やはりチューニングの目的は巨大なファイルを転送する処理が多いか少ないかまた、その頻度だと思います。 もし、それほどのアクセス、やり取りするファイルが少ないならばやらない方がいい場合もあります。 まず、基本はネットワークの高速化に役立つパラメータはNetwork Bufferというものです。 デフォルトでは、例えばtcp bufferサイズは小さいのでこれを大きくすると高速化が狙えます。 それでは、実際に現在設定されているサイズを確認してみましょう。 (tcp_memory) $ cat /proc/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く