mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
C++ のヘッダファイルを #include するだけで使える GC 書いてみた - kazuhoのメモ置き場
そういえば C++ のヘッダファイルを #include するだけで使える GC を書きました。使い方は下のサンプルコードを見てもらえばいいとして、特徴としては、 ヘッダファイルを #include するだけで使える C++ の標準機能だけを使っているのでポータブル*1 mark-and-sweep, precise GC ってなあたりでしょうか。コードは GitHub - kazuho/picogc: a tiny, portable, precise, mark-and-sweep GC in C++ にあります。 C++ のプロジェクトで、ちょっとここだけは GC がほしいんだけど、ってなケースで使いやすいと思います。速度も、そこそこでるんじゃないかな*2。 というわけで、以下、サンプルコード。軽く説明しておくと、 GC を使うクラスは picogc::gc_object を継承する
僕が shared_ptr よりも retain() / release() 方式が好きだと思う理由 - kazuhoのメモ置き場
それは、shared_ptr のようなラッパーよりも、オブジェクト自体が参照カウンタをもっているほうがコードが書きやすいから。 たとえば、継承したクラスでオブジェクトの参照カウントをいじることは、shared_ptr では難しい。 shared_ptr を使った場合： class Base { public: virtual void foo() = 0; }; class Derived : public Base { public: virtual void foo() { // ここで自分自身への参照カウンタをインクリメントしたいけどできない… gManager_.register(this); }; // 呼び出し側 obj = shared_ptr<Base>(new Derived()); obj->foo();オブジェクト自体が参照カウンタをもっていれば、このような問題は発生
[メモ] TCP/IPプログラミングにおけるエラー処理 (RSTパケットの飛ばし方と検出の仕方) - kazuhoのメモ置き場
SO_LINGER の秒数を 0 にしてソケットを閉じればいい。Perl で書くなら以下のような感じ。 setsockopt($sock, SOL_SOCKET, SO_LINGER, pack("II", 1, 0)) or die $!; $sock->close() 一方で RST によって切断 (＝異常切断された) かどうかはソケットからの読み込みが ECONNRESET エラーを返すかどうかで判断できる（正常切断なら 0 (==EOF) が返る)。
![[メモ] TCP/IPプログラミングにおけるエラー処理 (RSTパケットの飛ばし方と検出の仕方) - kazuhoのメモ置き場](https://cdn-ak-scissors.b.st-hatena.com/image/square/7094f829d5f0ef6ce8729219f846ece7e12712b0/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127106341284%2F17680117127106348519%2F1556845903)
HTTP/1.1 の chunked encoding を使った POST / PUT を避けるべき理由 - kazuhoのメモ置き場
通信相手のサーバが HTTP/1.1 対応と確認できるまでは 1.0 と互換性のない chunked encoding は使えないし でも確認が取れた接続を使い回す = HTTP/1.1 の持続的接続を使い回して POST / PUT するってことだけど、持続的接続のタイムアウト条件は、TCP 接続確立後初回のリクエストより厳しいし 従って、POST / PUT は、べき等性がないリクエストだから持続的接続には投げるのは避けた方が無難だし ということで、基本使うべきじゃない。という話をした (http://github.com/tokuhirom/p5-Furl/commit/67c3ea52a23542a44e58869d0bcebcb53becd34a)。
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 |
IPC::Open3 の正しい使い方 (re .pl な config ファイルのコンパイルがとおるかチェックしてみる - TokuLog 改メ tokuhirom’s blog) - kazuhoのメモ置き場
http://d.hatena.ne.jp/tokuhirom/20100813/1281666615 の件ですが、IPC::Open3 の使い方が気になったので、勝手に添削 (c) dankogai。 use IPC::Open3; ... my($wtr, $rdr, $err); my @cmd = ($^X, (map { "-I$_" } grep { !ref $_ } @INC), '-c', $file); my $pid = open3($wtr, $rdr, $err, @cmd); waitpid($pid, 0); IPC::Open3 は子プロセスの標準入出力と標準エラー出力を、親プロセスとパイプでつないでプロセス間通信を行うための仕組みです。 パイプには一定サイズのバッファがあり (Linux だと 4KB)、パイプにこれを超える大きさのデータが書き込まれると、
ファイルを追記モードで開くとseekできない、という話 (C言語の高水準I/OとかPerlとか) - kazuhoのメモ置き場
C言語に初めて触ってから20年のロートルですが今まで知りませんでした。man fopen より。 The fopen() function opens the file whose name is the string pointed to by filename and associates a stream with it. ``a'' Open for writing. The file is created if it does not exist. The stream is positioned at the end of the file. Subsequent writes to the file will always end up at the then current end of file, irrespective of any intervening fseek
XenServer と KVM のネットワークレイテンシ比較 - kazuhoのメモ置き場
どちらのサーバも、秒間数十の HTTP 接続をハンドリングしている状態で、ping -c 100 で測定した平均値。 ホスト ゲスト XenServer*1 0.138 1.295 KVM*2 0.130 10.590 KVM のゲストだけが遅い。常に遅いっていうんじゃなくて、時々ひっかかる感じ。ping の出力 (rtt min/avg/max/mdev) を並べてみると以下のとおり。RTT で 0.1 秒以上かかったりする (しかもそういう状態が続く) ので、ssh を使ってると、まるで海外のサーバにつないでるみたいな感じになったり。 xen host: 0.095/0.138/1.238/0.116 ms xen guest: 0.111/1.295/42.471/6.023 ms kvm host: 0.060/0.130/0.334/0.070 ms kvm guest: 0.2
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
ウェブアプリケーションサーバを複数台構成とか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-DBシステム構築／運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか？ - kazuhoのメモ置き場
松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめた本はないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築／運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな
アプリケーションサーバで非同期処理をするかしないかの分水嶺 - kazuhoのメモ置き場
mala さんのまとめは、わかりやすいなぁと思いました。ただ、傍論なんですが、 既存のマルチスレッド/マルチプロセスのサーバーで、常にリクエスト処理待ちの待機しているプロセスがある状態の場合は(+その並列数でCPUのパフォーマンスが劣化しない場合は)、パフォーマンスが劣化することは無いので非同期処理を使う必要が無いでしょう。実際のところ「1秒あたりに来るリクエストの最大件数」というのは予測できないので、(long-pollやstreamingをしない)普通のアプリケーションにおいても非同期処理の導入はメリットになる(と、考えている)。 非同期アプリケーションサーバーの要件と必要性について - 金利0無利息キャッシング – キャッシングできます - subtech はちょっと気になった。私見では、非同期処理 (スレッド内での I/O 多重化) を行うべきか否か、は、クライアントとの TCP
シングルマスタ／マルチスレーブ構成に興味がない理由 - 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台と、一気にコス
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場
syscall って組込関数でシステムコールはできますけど、libc やその他ライブラリの関数を呼びたい、ってこともありますよね。i386 かつ dlopen な環境なら、こんな風に書けます。 use DynaLoader; use ops; sub ccall { my $r = '1111'; my $s = "\x68" . pack("L", $_[5]) . "\x68" . pack("L", $_[4]) . "\x68" . pack("L", $_[3]) . "\x68" . pack("L", $_[2]) . "\x68" . pack("L", $_[1]) . "\xb8" . pack("L", ("Dyna"."Loader")->can("dl_find_symbol")->(("Dyna"."Loader")->can("dl_load_file")->
CPAN 階層の深いモジュール王選手権 - kazuhoのメモ置き場
CPAN 長いネームスペース大会 - にぽたん研究所 を見て、階層の深さだとどうなるかなと思ってやってみた。 1: perfSONAR_PS::Datatypes::v2_0::nmtl3::Topology::Domain::Node::Port::IpAddress 1: perfSONAR_PS::Datatypes::v2_0::nmtl4::Message::Metadata::Subject::EndPointPair::EndPoint 1: perfSONAR_PS::Datatypes::v2_0::nmwg::Message::Data::Key::Parameters::Parameter 1: perfSONAR_PS::Datatypes::v2_0::nmwg::Message::Metadata::Key::Parameters::Parameter 1: p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクリプトの並走度を２以上に制限する話 - kazuhoのメモ置き場
Q. UTF-8 の冗長性問題は、設計上の問題なのか? - kazuhoのメモ置き場
