同時にwrite(2)すると混ざるかどうか - kazuhoのメモ置き場
Linux のシステムコールである write(2) の ドキュメントを読むと Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. This is useful when there are multiple writers sending data to a single reader. Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}. This volume of
node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
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 |
Apache を daemontools で管理する - kazuhoのメモ置き場
自作のサーバプログラムに、いちいち setuid とか setsid とかログローテート機能とか実装するのめんどくさいわけで。だから daemontools を使って管理してるわけですが、だったら、いっそ全部のデーモンを daemontools で一括管理したい。 ちょうど、reverse proxy をセットアップする機会があったので、apache を daemontools で管理する方法を備忘録をかねてメモ。 % cat /service/httpd/run #!/bin/sh APACHE_ROOT=/usr/local/apache-2.2.14 exec 2>&1 exec pgrphack $APACHE_ROOT/bin/httpd -DNO_DETACH -DFOREGROUND -c "ErrorLog /dev/fd/1" -c "Include /var/httpd
C/C++に文字エンコーディングバリデーション機能がないって、ほんと？ - kazuhoのメモ置き場
通りすがり (2009-09-16 18:09) > PHP以外の言語は「(略)」のに対し ここに挙げられている言語がWebアプリで使われる全ての言語ではない。 例えば、CやC++にはない。付け足せば、PHPやPerlなどのCモジュール内部で起こった不正な文字はスルーされうる。 よって、「Perl、Java、.NET、Ruby、PHPの中では」と書けば筋は通るが、「PHP以外では」は誤り。 そしてそんなことを、PHPの(脆弱性撲滅に注力している)開発者に言ったら、喧嘩を売られたと受け止められて当然。 PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14) というコメントが気になった。 C言語にある文字コード変換機能って言ったら mbtowc だと思うけど、mbtowc は無効なバイト列を受け取ると EILSEQ を返すことに
「Linux-DBシステム構築／運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか？ - kazuhoのメモ置き場
松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめた本はないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築／運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな
FastCGI プロトコルってなんのためにあるのかわからない - kazuhoのメモ置き場
どういう場合に便利なんだっけ。てか HTTP プロトコルでいいじゃんみたいな。 たとえば httpd とアプリケーションサーバを分割するような環境なら、apache + fastcgi external server みたいな構成よりも、apache (mod_proxy + mod_proxy_balancer) + apache (mod_perl) とかのほうが柔軟だし。 あるいは、apache + fastcgi external server みたいなのを組むよりも、apache (mod_proxy + mod_proxy_balancer) + HTTP::Server::Simple (Net::Server::Prefork) でいいんじゃないかみたいな。 unix socket を動的に作成して通信、みたいたことをする場合でも、独自プロトコルな必要ってないんじゃないのか
SSD がコモディティになっても状況はかわらない - kazuhoのメモ置き場
脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。 この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。
MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 - kazuhoのメモ置き場
useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a problem? Because users do not clean up/close unused prepared statements. Multiply the number of prep
Q. 1GB の文字列を strlen するのに必要な時間は？ - id:kazuhookuのメモ置き場
1GB の文字列を strlen するのに必要な時間は何秒でしょう？ こういったものをぱっと予測できることは、最適化に取り組む上で必要かなぁ、と思ったので、自分の理解が正しいか確認するためにも、実測してみました。 (以下、白地に白文字で書いてあるので、選択して読んでください) 手元の Linux (Pentium 4 @ 3GHz / DDR2-667) では、約 0.48 秒 (2.1GB/sec)。GCC の組み込み程度の strlen では、ボトルネックはメインメモリの帯域あるいはレイテンシではなく、CPU になります。 一方、SSE で記述された strlen *1 を使用すると 0.26 秒 (3.9GB/sec)。こちらはメモリ帯域がボトルネックになっているようで、手元の MacBook (Core 2 Duo @ 2GHz / DDR2-667) でも、ほとんど同じ数値になり
ストレージエンジンを書くにあたって知っているといいかもな知識 - kazuhoのメモ置き場
ってどのあたりなんだろ。マインドマップ的に。 たとえば memcached のストレージ書くなら、 I/O API p?(read|write)v, fsync async API? Memory Mapping API mmap, msync Multithreading pthread API various locks: mutex, rwlock, etc. あたりかなぁ。耐障害性が必要になってくるなら、 Block Device HDD, SSD block size, random vs. sequential access, etc. Journalling Replication あたりも必要？ より本格的なストレージを書くなら MVCC Transaction Data Arrangement logging, indexing, cluster index, row-b
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT大手企業の４半期決算を比べてみる (億ドル) - id:kazuhookuのメモ置き場