Push Framework - A C++ toolkit for high performance server development
Write asynchronous, multithreaded servers in a few lines of code. Monitor realtime activity with a deploy-only dashboard. Download library source code (VC++ 2008) - 133 KBDownload library essentials (lib + public headers + DLL) - 70.9 KBDownload demo 1: Chat application (Server + Client + XMLProtocol + TCPSocket Module) - 292 KBDownload demo 2: Google ProtoBuf integration example (Server + Client
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta
自分のサーバの性能を知っておく - tokuhirom's blog
http://github.com/kazuho/manymanythreads ↑kazuhoさんがCで書いたエコーサーバーと、そのベンチマークツールによって、自分のサーバでどんぐらいのQPSがでるのかがわかる。 たとえば自分のマシン(SC440)だと ./testechoclient -c 1 -n 1000000 -f -p 5050で、 77906.624081 reqs./sec. (1000000 in 12.835879 seconds)ぐらいでる。 一番単純なエコーサーバーをうごかしたときの性能を把握しておくことによって、どのぐらいの速度がでてしかるべきなのかが把握できるようになるという。 【追記】 ここで知った echo server の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
