デシリアライズ速度の比較 ByteBuffer vs DirectBuffer vs Unsafe vs C - Blog by Sadayuki Furuhashi
OpenJDK や Hotspot VM には sun.misc.Unsafe という内部APIがあり*1、これを使うと ByteBuffer.getInt や ByteBuffer.getLong よりも高速にバイト列から整数値をデコードできるという。これを駆使することで、Cで実装された拡張ライブラリに匹敵する速度を出せるらしい。 それが本当なら、データ圧縮やハッシュ関数、シリアライザ/デシリアライザなどの実装を高速化できる。例えば、lz4 や xxhash のJava実装が Unsafe API を使用している*2：jpountz/lz4-java Prestoも、中間データのシリアライズ/デシリアライズにはすべて Unsafe API を使っている*3。 そこで、実際にベンチマークしてみた。 ベンチマーク内容 10MBのランダムなバイト列を生成する 先頭から1バイト読み出す その1バ
データベース負荷テストツールまとめ(2) - SH2の日記
データベース負荷テストツールまとめの第2回です。 前回はTPC-Bベース、TPC-Wベースのものから6つのツールをご紹介しました。今回はTPC-Cベースのものについて見ていきたいと思います。 tpcc-mysql 対応RDBMS：MySQL 対応OS：Linuxなど 言語：C 作者：Percona Inc. ライセンス：不明(ライセンスに関する記述がない) トランザクション仕様：TPC-Cベース URL：https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql tpcc-mysqlはMySQLのコンサル会社であるPercona Inc.によって開発されたベンチマークツールで、TPC-Cをベースとしています。TPC-Cの仕様やtpcc-mysqlについては以前のエントリで詳しく扱っているので、そちらをご覧ください。 tpc
HandlerSocketソースコード公開しました | BLOG - DeNA Engineering
はじめまして、樋口と申します。 先日のDeNA Technology Seminar #2でお話させていただきました HandlerSocket Plugin for MySQL のソースコードを公開しました。 HandlerSocketとは？ 簡単に言うと、MySQLデータベースへのアクセスを高速化するためのプラグインです。MySQLのSQLパーザをすっ飛ばし、ネットワーク通信とマルチスレッド処理周辺を置き換えることによって、InnoDB等のデータベースエンジンの性能を限界まで引き出します。 このHandlerSocketですが、すでにモバゲータウンにて実際に運用しています。従来MySQLとmemcachedの構成で運用していた箇所を、HanderSocketを組み込んだMySQLだけの構成に置き換えました。その結果、MySQLサーバの負荷軽減、memcachedの負荷軽減、ネットワーク
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
Cybozu Inside Out: ScaleBench 公開
どーもみなさま。こんにちは。 amachang と申します。 さて、ようやく ScaleBench というプロダクトが発表されましたね！ ScaleBench のご紹介 で、僕もこれの開発に携わっていたのでちょっと技術的なことについて書いてみたいと思います。 ScaleBench とは ScaleBench とは、サイボウズ製品向けの負荷テストツールで Grinder というオープンソースの負荷テストツールをベースにしています。 Grinder とは Java を使った Web の負荷テストツールです。 Jython でシナリオ（ユーザがどう行動するか）を書いてそれを実行します。 またブラウザの操作を記録して、シナリオを自動で生成することもできたりします。 で、僕がこのプロジェクトで担当していたのが Grinder の改良、改造 シナリオ（バーチャルユーザがどのような順で負荷をかけていくか
Rubyの文字列の連結速度を測定してGruffで表示してみた - suer のブログ
String と StringBuffer の文字列連結速度のテスト - すえひろがりっっっっ!と同様小ネタ。 社会人になって1年たちますが、仕事で「素人かよ！」って思うコードをよく見かけます。 そのトップ10に入るのが「Javaで+= で文字列を連結していてパフォーマンスがすこぶる悪い」コードです。 これをやってた人は、いまだに += で文字列を連結しているコードをよこしてきます。 どうにかならないもんだろうか。 ところで、Ruby でも String の連結は重いのだよね？とふと思ったので += と << で結合した場合の速度を測定してみました。 楽しいRubyによると Ruby でも += で結合するとインスタンスを生成するらしい。 ということは += と << では性能に差が出るはず。 せっかくRubyなのでGruffを試してみます。 バージョン Mac OS X 10.6.3 C
Apache2+mod_proxy+持続接続で時々レスポンスが悪くなる現象のメモ - Pixel Pedals of Tomakomai
今更な話題で恐縮ですがmiyagawaさんがものすごい勢いで教えてくれたのでメモっておきます。 mod_proxyでバックエンドにリクエストを投げたとき、リクエストのうち何個かが極端に遅いという現象が起こりました。その時のabの結果は以下。 % ab -c 5 -n 500 http://127.0.0.1:21082/ Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 4 95% 1008 98% 1994 99% 2003 100% 2020 (longest request)なお、今回使おうとしたバックエンドはStarmanです。 多分こんな原因 検証不足で断言はできないのですが、多分以下のような感じ。多分。 Apache のデフォルトのServerLimi
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
IPA、業務システムでRubyを用いるためのチューニング手法と課題を公表 | エンタープライズ | マイコミジャーナル
IPA(情報処理推進機構)は9月7日、「自治体・企業等の情報システムへのRuby適用可能性に関する調査」の報告書を公開した。同調査ではRubyについて、自治体や企業などの業務システムの開発といった分野を想定し、機能面・非機能面からその適用性の評価を行った。 調査を実施したのは、「Enterprise Ruby コンソーシアム(テクノプロジェクト、みずほ情報総研)」。検証環境は、富士通の「Platform Solution Center」に設けられた検証ルームと検証用機器が用いられた。 富士通「Platform Solution Center」のサーバルームと検証ルーム 同検証の目的は、Rubyを用いた「入出力処理」、入出力処理によって構成される「アプリケーションとしての処理プロセス」を想定したベンチマークを取得し、幅広いアプリケーション開発にRubyを用いる際に参考となる計測データやチュー
もっと速くするために(スコープ解決コストと正規表現オブジェクトの置き場所) - latest log
正規表現オブジェクトをどのように配置すれば効率的なのか調べました。 配置パターン A. ループ内にべた書き function job(expr, n) { var i = 0, match; for (var i = 0; i < n; ++i) { match = /regexp1/.exec(expr); match = /regexp2/.exec(expr); } } B. スコープ内(ループの外)に配置 function job(expr, n) { var i = 0, match, REX1 = /regexp1/, REX2 = /regexp2/; for (var i = 0; i < n; ++i) { match = REX1.exec(expr); match = REX2.exec(expr); } } C. 5つ外側のスコープに配置 (function() {
シングルマスタ／マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場
システム全体で必要な書き込みパフォーマンスが、RDBMSノード１基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ／マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが２倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ／マルチスレーブ構成では16台と、一気にコス
パフォーマンスチューニングする時の基礎の基礎 - 宇宙行きたい
みんなパフォーマンスチューニングの環境とかってどうやってるのかなぁと 思ったので書いてみますた． 全然専門外なのでまったく自信無いですが，僕はこうやってるよって事で まずは普通に実装 最初からパフォーマンスを気にして書いちゃうと， 何が有効で何があまり有効でないかわからなくなっちゃうので， とりあえず普通に実装する． (ifelse より switch の方が早いとかやっても微々たるものだし) もちろん，後々のために TDD でやっておく． 計測環境を作る テストケースとして記載する 重い処理を探すために，100回くらい繰り返して実行して 平均を見れるようにする． Java の実行時最適化とかの影響もあると思うので， 最初の一回の時間と平均を見れるようにする． assert も書いておくと，何秒以内を目指すのかが， 残せるので書いておく． StopWatch stopWatch = new
WicketのCPU負荷について調べてみた - 矢野勉のはてな日記
Java, Wicketid:s-ishigamiさんがWicketのCPU負荷について調べていて、IMarkupSettingsのsetAutoLinkEnabled(true)をしていると負荷がとても上がって困るって話でした。いやいやそれはおかしいと思って調べてました。...と言ってる間に、id:s-ishigamiさんも継続調査していて似たような方向に調査が向かっているようですが、せっかく調べたので書いておきます。 もとねた：WicketのCPU負荷 - s-ishigamiの仕事日記（WicketでECを作る道のり）WicketのCPU負荷〜その２〜 - s-ishigamiの仕事日記（WicketでECを作る道のり）WicketのCPU負荷〜その３〜 - s-ishigamiの仕事日記（WicketでECを作る道のり）WicketのCPU負荷〜その４〜 - s-ishigamiの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
httpd.confによるWebサーバの最適化