セッション管理モジュールやルーティングライブラリが速くなる事で何もしなくても isucon3 予選のperlのアプリケーションが高速化していく— masahiro nagano (@kazeburo) October 10, 2013 ということで、やってみた。 初期 「オンライン予選で使用した問題が手元で再現できるAMIを公開しました」に書かれているAMIを使って起動し、まず、初期状態でのベンチマークを取ってみる。 2013/10/28 14:21:18 done benchmark Result: SUCCESS RawScore: 865.9 Fails: 0 Score: 865.9 disble? たぶんミスだと思うのですが、Starmanの起動オプションがdisbleになっていたので修正 - command=/home/isucon/env.sh carton exec --
AさんはRailsで書かれたある遅いコードの検証をしていました。 X-Runtimeヘッダを見ると $ curl -Is localhost:3000/hello | grep X-Runtime X-Runtime: 5.008580 5秒もかかってる。 しかしRailsのログを見ると Started HEAD "/hello" for 127.0.0.1 at Tue Apr 03 13:04:11 +0900 2012 Processing by HelloController#index as */* Rendered text template (0.0ms) Completed 200 OK in 10ms (Views: 9.7ms) こんな感じで10msで返していることになっている。なんだこれは？ こういう状況で疑わしいことの一つとして、Rack等のMiddlewareのど
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
正しいベンチマークをするための10のポイント
世の中ではたくさんの人が独自にベンチマークを行ない、独自に情報発信がされています。そのベンチマークの中には、非常に参考になるものもあれば、現実性に大きく欠けるものもあります。競合他社が、ライバル社の製品にとって不利な条件でベンチマークを行い、それを発信することも日常的に行われています。ベンチマークの結果を鵜呑みにすることは危険で、結果の意味を判断するスキルを持つことが重要です。これはプロジェクトにおいて負荷テストを行う場合にも重要です。負荷テストの条件設定が正しいかどうかを判断できるようになるためです。 ここでは、私がDBサーバのベンチマーク/負荷テストを行ったり結果を読んだりする上で、心がけているポイントを10個ほど紹介したいと思います。 ■ハードウェアに関する4つのポイント 1. ハードウェアのスペックと設定を注視する ハードウェア構成によってベンチマーク結果は劇的に変わるので、言わず
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
これの続き。 なんかかなりjitterがあるみたいでおかしな結果になってるんだけど、アルゴリズムごとの特徴は出てるので。 - Chrome FF3.0.5 FF3.1b2 IE6.0 IE8.0b2 Opera Safari WebKit/r40352 concat_op 32 203 150 747586 453 156 51.5 32 join 36 478 596.5 562.5 234.5 445.5 87.5 38 hybrid 5 99.5 108.5 156 195.5 195.5 23.5 18 newbulk 0 38 52.5 47 15.5 54.5 1.5 2 ちなみにnewbulkのコードは var newbulk = function(s, n) { var s, r = ''; while (n > 0) { if (n & 1) r += s; s += s
注意: FF3.1b2の結果が不正確です。取り直したのはこちら。 ちょっとした事情により、ある文字列のn回繰り返しを作る関数 (PHPでいうところのarray_repeat(), Perlで言うところの「"..." x n」、RubyやPythonで言うところの「"..." * n」) を高速に実装しなければならない状況に遭遇したのでベンチマークをとってみたところ、その結果がとても新鮮で驚いたので、これを共有しつつもダメ出ししてもらえないかなーと思って晒してみることに。 あらまし JavaScriptの文字列型 (およびStringオブジェクト) はJavaのようにイミュータブルなので、こういう文字列構築を行う方法としては、以前から、+や+=演算子を用いるよりも、一旦Array()に入れておき最後にjoin()するという方法が有効だと言われていてですね、まあ確かに、文字列用メモリ領域の確保
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
