RE2を試してみた。 - 初学者の箸置
Google Code Searchで使われている正規表現ライブラリRE2が公開された。 http://code.google.com/p/re2/ PCRE系のバックトラック式（指数的時間、どこまでも伸びるスタック）に変わるものとして、Ken Thompsonのopen source grepで使われている fast DFA方式（多項式時間、固定スタック）で実装されているらしい。ちょと試してみようかと。 まずはPCREの速度測定 http://swtch.com/~rsc/regexp/regexp1.html とのことで、試してみる。 PCREで(a?)^n(a)nをつくって実験。 #include <iostream> #include <string> #include <sys/time.h> #include <pcrecpp.h> long long gettime() {
encode/decode より find_encoding のが速いのは知ってたけどここまでか - だるろぐ
今更ネタが続く。 くりかえしdecode()とencode()する場合には、OOインターフェースを使った方が高速です。なぜなら(de|en)codeが文字コード名を解決する手間がなくなるからです。 404 Blog Not Found:perl - Encode 入門 と言われているのは知ってたけど実際は毎回 decode('euc-jp', $str) とかしてて実際どんくらい違うのかなーとふと思って use strict; use warnings; use Benchmark qw/:all/; use Encode qw/find_encoding encode decode/; my $euc = find_encoding('euc-jp'); my $utf = find_encoding('utf-8'); open my $fh, "<", "euc.txt"; my @
コンピュータサイエンス史上最大の課題「並列処理による性能向上」～情報処理学会創立50周年記念全国大会の招待講演
「いま、並列処理の壁というコンピュータサイエンス史上最大の課題に直面しています。しかしこれはチャンスでもあります。新しい時代を切り開いていきましょう」。IBM名誉フェローのFran Allen氏は、昨日3月10日に行われた日本の情報処理学会創立50周年記念全国大会の招待講演の演壇からこんなメッセージを聴衆に投げかけました。 Fran Allen氏は、コンパイラやプログラミング言語が専門で、女性で初めてチューリング賞を受賞した人。今回の招待講演のためにわざわざ来日したと紹介されました。 講演のタイトルは「The Challenge of the Multicores」。ここからは、Allen氏の講演の内容を紹介しましょう。 （この講演は英語で行われたものです。内容にはできるだけ正確を期したつもりですが、理解不足のところや聞き取れなかったところもありました。もし誤解や不正確なところがありました
Twitterのクジラ解剖学、あるいは彼らがいかにサーバの処理能力を向上させたか
Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」（クジラの解剖学）では、Twitterのエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T
HipHop for PHP | Carpe Diem
HipHop for PHP の技術的な講演動画が ustream にあったので、チェックしてみました。動画は、全部で 40 分弱くらいですが、講演自体は 20 分くらい、その他は質問でした。 以下、動画からのメモです。 CPU の高い使用率が問題になっていた 10,000 台のウェブサーバ それぞれのリクエストに 800 ミリ秒かかっている コードベースが巨大になるにつれて、さらに遅くなる ハードウェアは、フリーではない 言語ごとのベンチマークした結果の CPU の使用率 CPU の使用率が低い順 No1: C++, No2: Java, No3: C#, No4: Erlang, No5: Python, No6: Perl, No7: PHP PHP と Perl は同等、C++ や Java に比べると10 倍くらい遅いという結果 高いメモリ使用率が問題 – 150M for (
Faster.pm の中身の話 - tokuhirom's blog
mlehmann の Faster.pm という Perl 用 JIT があるのだが、これの仕組み。 op_entersub をフックするop_entersub にはいるタイミングで発動! op tree を C のコードに変換するcc するdynaloader でよみこむといった具合。基本的には Shibuya.pm で発表済のだれでもしっているようなテクニックをつかっている。 これはだいたい 20% ぐらいはやくなるらしい。まあ妥当なかんじか。とはいえテストとおらないしまともにうごかないので、本当かどうかはわからない。 結局 run_ops まわりの部分がインラインで最適化されるという点におけるメリットぐらいで、各 opcode の操作はそれぞれの中でやっているわけだから、納得できる数字かとおもう。ただ、実際にそのテストにつかったコードってのがないんで、なんともいえないけど。 実用とい
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない) というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連 iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_max ip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて
ウェブ業界の15年、これからの10年 (Re ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) - kazuhoのメモ置き場
先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの
ウェブアプリケーションサーバを複数台構成とか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 とすると、
[D] namebench ~ オープンソース DNSベンチマーク ~
日本では、一般家庭にギガビットな光回線が提供され始めたりしてるそうですが、インターネット、特にWeb browsingの体感的な快適度は、単なる回線速度だけによりません。DNSによる名前解決のスピードは、まさに、Webの初速を決める要素で、体感的にも大きく影響を与えます。最近では、Googleが提供する高速DNSが話題になったりしてますが、そのGoogleの20%プロジェクトによる、DNSの性能を簡単に測定するベンチマークソフトを発見しました。 その名もnamebench。Mac, Win, Linuxで動くアプリケーションで、起動してStart Benchボタンを押すだけで、あとは、様々なDNSのパフォーマンスを測定し、自動的に最適なDNSをオススメしてくれます。 結果画面はこんな感じ。とりあえず右上にオススメされるPrimary/Secondary Serverあたりを適応するだけで、
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか:Web屋のネタ帳 on CNET - CNET Japan
結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。 一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。 筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。 あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。 Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Availability) 「えっ？そうだったの？だとすれば、、、」というのが筆者の素直な感想である。これだけでピンと来ている人はいいのだが、詳しくない人のために
Varnish - Trac
Welcome to the Varnish project Varnish is a state-of-the-art, high-performance HTTP accelerator. It uses the advanced features in Linux 2.6, FreeBSD 6/7 and Solaris 10 to achieve its high performance. Some of the features include A modern design VCL - a very flexible configuration language Load balancing with health checking of backends Partial support for ESI (the sensible part of ESI) URL rewr
プログラミング言語の特徴を視覚的に比較する - Radium Software
The Computer Language Benchmarks Game のページでは，計 32 個のプログラミング言語処理系のベンチマークを集計して，そのパフォーマンスを比較している。そして最近，このページに新たなプロットが追加された。単純にパフォーマンスだけの比較を行うのではなく，パフォーマンスと「コードの長さ」を関連付けて比較を行うというものだ。上はそのプロットから一部を転載したもので，全体はこのページで見ることができる。 このプロットでは，縦軸が処理時間（上にいくほど遅い），横軸がコードの長さ（右にいくほど冗長）に割り当てられている。このようなプロットを行うと，多くの言語は３通りの偏り方を見せる ― 左上（簡潔だけど遅い）に偏る「スクリプト系」，右下（速いけど冗長）に偏る「システム系」，そして，左下（速くて簡潔！）に偏る「理想系」だ。ちなみに，右上（遅くて冗長）に偏る言語は無い…
自分のサーバの性能を知っておく - 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 の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
Firefox もったいない!!! - gaeの日記 #3.1 「nowa owata」
IE8はJavaScriptの遅さばかり気にしていたけど、普通に使ってみると確かに速いなー。リンクをクリックしてからページが表示されるまでのスピードは、Firefoxより倍くらい速い感じがする。 いろんなサイトで見比べていくうちに「いくらなんでもFirefoxは遅すぎだろう」と思い始めたので、いつもスルーしてるFirefoxを高速化するTipsを見てみたら、あった。about:configで「新規作成(整数値)」で「nglayout.initialpaint.delay」を作って「0」を設定するこれで体感速度が超改善した。 これは設定しないともったいない!!! あと、IEのリンクをクリックしたときにカチカチ鳴るやつ。あれは、やっぱり良いなーと思ったので、アドオン入れてみた。Navigational Sounds :: Firefox Add-onsこれでIEみたいにカチカチなるようになった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Yahoo!ニュース」の表示速度が3～5倍に、そのからくりは……：記事の芽
