mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
ドキュメントとテストコードつきのPerlスクリプトを書く方法 - kazuhoのメモ置き場
Re http://d.hatena.ne.jp/perlcodesample/20091130/1258979624, http://mt.endeworks.jp/d-6/2009/12/scriptsubimport.html スクリプトとコードとテストを単一のファイルにまとめたい*1という需要が、かねて自分の中であったので教えを請うた結果、以下のような感じで書けばいいことがわかった。 #! /usr/bin/perl use modules...; my $global = ...; sub foo { ... } sub bar { ... } run_tests() if $ENV{HARNESS_ACTIVE}; # メインのコード foo(); bar(); ... sub run_tests { ... exit; } __END__ =head1 NAME my_scr
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
WebSocket(RFC 6455)上で使用するプロトコル設計についての備忘録 - kazuhoのメモ置き場
一般論として、全二重の通信プロトコルを実装するにあたっては、いくつか注意すべき点があって、具体的には、到達確認と切断シーケンスについて定めておかないと、送達されたはずのメッセージがロストしていたり、切断タイミングによってエラーが発生*1したりする。 具体例をあげると、たとえばTCP/IPにおいてshutdown(2)を用いずに、いきなりclose(2)を呼んでいると、read(2)やwrite(2)がエラー(ECONNRESET)を返す場合がある。 翻って、WebSocket (RFC6455)の場合はどうなってるか？ だいたい以下のような感じっぽい。 ws.close()が呼び出されるとWebSocketをCLOSING状態に変更し、Closeフレームを送信する ws.onmessageはWebCosketがCLOSING状態にある間も呼ばれるかもしれない*2 相手からCloseフレーム
nicesort ってのを書いてみた - kazuhoのメモ置き場
sleep sort とか環境にやさしすぎて21世紀には不向きだと思うの。なので nicesort なるものを作ってみた。 #! /bin/bash function f() { nice -n "$1" perl -we 'for (1..1000000) {}' echo "$1" } while [ -n "$1" ] ; do f "$1" & shift done wait こんな感じで動きます。注意点としては、マルチコアだとうまく動かないので taskset 使いましょう (linux の場合) ってのと、0-20の範囲でしかそーとできないよってあたりかしら. $ taskset 1 ./nicesort.sh 1 9 6 4 1 4 6 9ちなみに、nice 値が１増えると実行時間は1.25倍になる。これは試験に出るよ！ 参考: 革命の日々！ CFSのnice値について
TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係) - kazuhoのメモ置き場
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
Disk I/Oの使用率を監視するワンライナー - kazuhoのメモ置き場
iostat -x の %util を監視してしきい値を超えたらアラートメール飛ばしたいなぁと思って crontab 書いた。こんな感じ。 */5 * * * * perl -wle 'my $s = `/usr/bin/iostat -xk /dev/sd[abc] 270 2 | tail -4`; print $s if $s =~ m{\s(?:[0-9]{3}|[5-9][0-9])\.[0-9]+$}m'ポイントは、 iostat の後ろから２つ目の引数がサンプリングを行う秒数 tail で デバイス数+1 することで、最後のサンプルを取り出す 正規表現で50%以上だった場合に標準出力に iostat の結果を出す＝メール送信
彼氏が LIKE 検索使ってた。別れたい… (もしくは Solr 入門とか Tritonn のインクリメンタルバックアップとか) - kazuhoのメモ置き場
LIKE 検索だとデータ増えてきた時なんか恥ずかしいwww 下向いちゃうしww 男にはせめて全文検索エンジン使ってほしい・・・ 検索が遅すぎてユーザー帰っちゃったら・・・・もう最悪www せめて普通 Tritonn や Solr くらいは使って欲しい。 常識的に考えて欲しいだけなんです！ 「%」検索されて全件マッチしちゃった時の恥ずかしさとか分かる？ あのね？たとえば１年間で10万件とか文書がたまるでしょ？ それを格納して検索するわけじゃない？ みんな普通に形態素解析とかn-gramとか期待してるわけでしょ？ LIKE検索でタイムアウトしてたら大恥かくでしょうがww とまあ、検索するなら全文検索エンジン使うしかないわけですが。じゃあ何を使うべきか。 自分は、ながらく Senna をベースにした MySQL の全文検索拡張 Tritonn のユーザーで、自分で機能追加のパッチも書いたりしてい
ウェブ業界の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 とすると、
linuxで httpd が使ってるメモリ総量を調べる話 - kazuhoのメモ置き場
Perl等のLLでウェブアプリケーションサーバを書いていると、普通はマルチプロセスモデル (apache なら prefork とか) で運用することになると思う。で、それらがどれだけメモリを使っているか、っていうのはチューニングにおいて重要になってきたりする (んじゃないかと思う) けど、そもそもメモリの総使用量をどうやって測定するのか。 20:20追記: PSSを使ってワンライナーで測定するのが簡単 (コメント欄参照)。kosakiさんありがとうございます。 $ sudo perl -le 'for my $p (@ARGV) { open my $fh, "< /proc/$p/smaps" or die $!; map { /^Pss:\s*(\d+)/i and $s += $1 } <$fh> } print $s' `pgrep plackup` 914325以下は初回投稿時
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
SSD とストレージの将来 - kazuhoのメモ置き場
SQL に痛痒感を感じる日々を過ごしている身としては、RDBMS がレガシーだというのは、まったく同感ですが。 SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。 2008-12-12 そんなことないと思います。理由は以下の２点。 フラッシュの書き換えブロックサイズは数キロバイト以上 トランザクションは意識して実装せざるを得ない フラッシュメモリはランダムリードできますが、DRAM のようにランダムライトできるわけではありません。書き込みが非常に遅いのに加えて書き換え回数の制限もあるので、メインメモリと同様のプログラム手法を使うのは難しいと思います。 次にトランザクションについてですが、組み込み型データベースとして
MySQL の filesort プチテクニック - kazuhoのメモ置き場
MySQL のチューニング関連のドキュメントを読んでいると「ORDER BY を避けろ」と書いてあるけど、できない (or したくない) 場合もあるわけで。そういう時はソート用の表と表示用の表を分割し自己結合することで、高速化できることもあります。適当な例ですが、 mysql> SHOW CREATE TABLE testt\G *************************** 1. row *************************** Table: testt Create Table: CREATE TABLE `testt` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `priority` int(10) unsigned NOT NULL, `data` varchar(255) NOT NULL, PRIMAR
NanoB というウェブアプリケションフレームワーク書いた - kazuhoのメモ置き場
MENTA (http://d.hatena.ne.jp/tokuhirom/20081112/1226460761) は事前コンパイル型だけど、キャッシュ方式でどこまでパフォーマンスが出るか。と同時に、CGI で最速 WAF を作ろうと思うと、コントローラ毎に index.cgi を生成するのが一番速いだろうというのは、合意が得られるところだろう。というわけで、apache のリクエストに応じて、cgi を動的に生成／更新するウェブアプリケーションフレームワークを作ってみました。あくまでも評価目的 (＝ネタ) なので、名前も NanoB というやる気のないもの。 結論： やや古い MENTA に対して 13% 増の速度 (156.67 reqs/s vs. 138.27 reqs/s) 取った手法としては、以下のとおり。 CGI 生成 CGI が、cache ディレクトリ以下にコントロー
memcpy 最適化 - kazuhoのメモ置き場
バイト単位でコピーするアホなコードの方が、勝手にベクトル化される分、gcc 内蔵のヤツより最大３倍高速なんだってwww memcpy() compiled with vectorizing compilers All current compilers for linux should support SSE2 auto-vectorization with #include <string.h> void *(memcpy)(void *restrict b, const void *restrict a, size_t n){ char *s1 = b; const char *s2 = a; for(; 0<n; --n)*s1++ = *s2++; return b; }(中略) x86-64 gcc memcpy() (中略) Linking in a user-compiled
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
