Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測する簡単な方法 - 人間とウェブの未来
単純に特定のURLに対してミドルウェアの性能を計測したい場合などには、今でもabやwrk、h2loadのようなシナリオベースではないシンプルなベンチマークはとても有用です。 一方で、最近ではgatlingやtsungといった、豊富な機能やリッチな計測結果を取得できるベンチマークソフトウェアも豊富になってきました。 ただ、例えば、単に「Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測したい」時に、僕のようなめんどくさがりの人間はcliで適当にオプションを渡して1回の実行でシュシュシュっと取りたいものですが、それができるツールが見当たらず、うーむ、gatlingやtsuningでやるかなぁとおもっていたところ、なんとApache Bench(ab)で簡単にシュシュシュっとできてしまうことに気づいたのでした。 ということでその方法を紹介します。例えば以下のような要件の時に
LMDB | symas
An ultra-fast, ultra-compact, crash-proof, key-value, embedded data store Symas LMDB is an extraordinarily fast, memory-efficient database we developed for the OpenLDAP Project. With memory-mapped files, LMDB has the read performance of a pure in-memory database while retaining the persistence of standard disk-based databases. Bottom line, with only 32KB of object code, LMDB may seem tiny. But it’
LevelDB Benchmarks
Google, July 2011 In order to test LevelDB's performance, we benchmark it against other well-established database implementations. We compare LevelDB (revision 39) against SQLite3 (version 3.7.6.3) and Kyoto Cabinet's (version 1.2.67) TreeDB (a B+Tree based key-value store). We would like to acknowledge Scott Hess and Mikio Hirabayashi for their suggestions and contributions to the SQLite3 and Kyo
[ユニットホスティング] IOPS測定してみた(暫定版/要確認) - 高原芳浩のKeep-Alive
自分でやっちゃったらダメだろうと思いますので、参考までに（信じないで >結果に自信が無いため、あえてあっちには書きません。また、ツールの使い方とか、値の見方がダメなので誰か分かる人の追試やっていただける方いたらお願いします。試験内容はニフティクラウドについてのこちらの記事です。http://d.hatena.ne.jp/kazuhooku/20100420/1271717051 randombenchを使いました。結果以下のようになりました。concurrency1416read208261827122write116111661278参考）元ネタの方にあったニフティクラウドの値。concurrency1416read137012601470write647793877何か腑に落ちないです、だれか助けて下さい。 試験結果詳細実行したコマンド./randombench.cc -b 16 -c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
