タグ

ブックマーク / kazuhooku.hatenadiary.org (4)

  • ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場

    タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の2倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を1台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を2倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、

    ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
    hamasta
    hamasta 2009/12/27
     こうやって計算するものなのか
  • 「Linux-DBシステム構築/運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか? - kazuhoのメモ置き場

    松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめたはないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築/運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな

    「Linux-DBシステム構築/運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか? - kazuhoのメモ置き場
  • リモートサーバに接続できない場合の telnet による原因切り分け方法 - kazuhoのメモ置き場

    1) telnet host port して Escape character is ... と出た後、すぐ (あるいは少しして) 接続が切れる → 接続後 fork() 等で落ちている → サーバのメモリ不足やプロセスの無限増殖を疑う 2) telnet host port して Escape character is ... と出るが、その後何も起こらない → SYN_ACK が返ってきている → カーネルは生きている。ユーザーランドの負荷が極めて高い可能性 3) telnet host port して、すぐ connection refused と出る → RST が返ってきている → port が閉じている (サーバプロセスが落ちた?) か、または accept(2) していない 4) telnet host port して、しばらくたってから connectin refused

    リモートサーバに接続できない場合の telnet による原因切り分け方法 - kazuhoのメモ置き場
  • MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場

    集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに1回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に

    MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
  • 1