※タイトルは釣りです。 先のエントリで、 採るべき技術的アプローチに関しては、ソフトウェアの修正コストによってかわるという議論があって、ウェブサービスの場合にはソフトウェア製品（やSI)と比べて圧倒的に修正コストが安い。ウェブサービスの場合にロケット科学的な「正しいけど大げさ」なアプローチよりも、小さく作って動かしながら修正していく手法が好まれるのにはそういう背景もある ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場 と書いた件、GCを例にあげて説明します。 ソフトウェアを製品として出荷するビジネスは、修正コストが高いです*1。企業向けソフトウェアなら、管理者がアップデートをインストールしなけりゃいけないし、それによって不具合が発生していないか結合試験が必要になるかもしれないし、場合によって南極まで出張して…ごにょごにょ。 こういう

まだ master にはマージしてないですが kazuho/user-defined-templates ブランチのやつを使うと、 class Adder.<T> { static function f(x : T, y : T) : T { return x + y; } } class Test { static function run() : void { var n = Adder.<number>.f(1, 3); log n; var s = Adder.<string>.f("abc", "def"); log s; } } が、最適化オプション (--optimize inline,fold-const) でコンパイル後に Test.run$ = function () { /** @type {!number} */ var n; /** @type {!string}

なぜ「速い」のか、について JSX 開発者の立場から。 たとえば、シューティングゲームで一番重たい処理は何か。言うまでもなく衝突判定。多数の弾や敵機の衝突判定を毎フレームごとに行う必要があり、この演算が重たい。 JSX に同梱されている web/example/shooting.jsx には衝突判定のコードが複数あるが、一番重たいのは Bullet#update 関数で、その処理は以下のようになっている*1。 for (var rockKey in st.rocks) { var rock = st.rocks[rockKey]; if (this.detectCollision(rock)) { if (rock.hp == 0) return false; inDisplay = false; if (--rock.hp == 0) { st.score = Math.min(st.s

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値について

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  | 

どういう場合に便利なんだっけ。てか 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 を動的に作成して通信、みたいたことをする場合でも、独自プロトコルな必要ってないんじゃないのか

_ djb が自作ツールの更新を放棄してからずいぶんたって、qmail やら djbdns やらはゆっくりと置き替えが進んでいるようだ。が、いまだに使い続けられているものもある。具体的には daemontools。いまだに daemontools を 使うネタが書かれているのを見て絶望した。代替物はほかにもあるのに。 (中略) _ そんなわけで、わしのことを anti djb だと思っている一部の方々が飽きて燃料投下を望んでいるような声をだいぶ前にどっか(どこだか忘れた)で見かけたので、要望に答えて若干 djb を dis り気味に runit と ipsvd を解説してみました。わしゃ別に「いいものを使う」というだけで、djb が嫌いなわけでもなんでもないんだけどね。ちなみに、自分自身では好き嫌い以前に必要性を感じてないので使っておりませぬ(これ書くために何年かぶりにインストールした)。

先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの

タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が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 とすると、

「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降

システム全体で必要な書き込みパフォーマンスが、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台と、一気にコス