Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に
Amazon の強さの秘密について考える - naoyaのはてなダイアリー
昨日 Amazon がなぜ強いかという話にちょっと触れたところ結構ブックマークされたようで、その反応がいろいろあって面白かった。言葉足らずだった部分も含めて、僕が Amazon がなぜ強いかについて考えるロジックをここにまとめてみたいと思います。 まず、実感を持ってもらうために以下のリンク(すべてサーチの検索結果です。) を実際にみてみて、Amazon.com なり Amazon.co.jp なりがどの辺りの位置につけているかを確認してみてください。 Google で「ワンダと巨像」 Google で「Agile Web Development with Rails」 Yahoo! Japanで「アドベントチルドレン」 Yahoo! Japanで「いま、会いにゆきます」 おそらく、楽天やほかのどのショッピングサイトよりも先に Amazon のリンクを目にすることかと思います。ここで羅列した
日経ビジネスの Amazon/Google の記事の感想 - naoyaのはてなダイアリー
今年9月、戦後日本の流通革命を主導したダイエー創業者、中内功氏が世を去った。大量生産、大量販売で大衆を煽るマス経済は終わり、消費者一人ひとりを個人名で呼び、その人のためにカスタマイズした製品、サービス、情報を提供する「ナノ経済」が始まった。 会社でたまたま目についた日経ビジネス、表紙にでかでかと「グーグル」「アマゾン」なんて書いてたものだから、気になって読んでみました。 先日 Amazon のIR発表で、日本における Amazon の売上高、つまりは Amazon.co.jp の売上高が Amazon 全体の 10% 以上あると発表されました。それを受けての分析がなされてる記事で、単純計算でも Amazon.co.jp の売上高は 800 億円に達し、結果 450 億円強の楽天にも大差をつけている、との話。それから紀伊国屋の売上高(1,184億円)との比較もあったりして、よくまとまっている
naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
naoyaのはてなダイアリー - Inside Flickr
phpspot開発日誌 で Flickr のシステム構成に関するプレゼン資料のサマリが載っていて、その PDF を見たところプログラマ1人デザイナー1人で作ってるとか PHP で Smarty を多用してるとか、MySQL InnoDB でほげほげとかあって面白かったわけですが、この PDF、一年くらい前のもののようでした。 ただ、Yahoo! に買収されるもっと前のものとはいえ、参考になるポイントはとても多く有益な資料であることはまちがいないですね。個人的には、プログラマ一人、というところに納得。逆に一人あるいは数人じゃなかったらどうしてあれだけのものが作れたか、不思議に思ってたところだと思います。 なお、このタイトルは Inside LiveJournal's Backend (PDF) をもじったものです。こういうケーススタディ的な資料が無料で見れるというのはすばらしい時代だなと思い
Apache 2.2.0 + mod_proxy_balancer - naoyaのはてなダイアリー
Apache 2.2.0 がついにリリースされまして、かねてから期待されていた mod_proxy_balancer が安定版で使えるようになりました。mod_proxy_balancer はその名のとおり Apache でロードバランスするための proxy モジュールです。詳しい解説は yappo さんがしてくれてるのでそちらを。 実は mod_proxy_balancer 使ってみるかーと思って Apache 2.2.0 をインストールしようとしたらいきなり躓きました。APR 1.2.0 が入ってないから駄目だよ! と configure に叱られまして、でも APR 1.2.0 って Apache 2.2.0 インストールしないと入らなくね? みたいな矛盾が発生しました。なので、まず最初に srclib にある APR をコンパイル & インストールして、その後 Apache2 の
naoyaのはてなダイアリー - JSON を Template-Toolkit で展開する Jemplate
Jemplate is a templating framework for Javascript that is built over Perl's Template Toolkit (TT2). Jemplate parses TT2 templates using the TT2 Perl framework, but with a twist. Instead of compiling the templates into Perl code, it compiles them into Javascript. かぜぶろさんや宮川さんがブックマークしてたので気になってちょっと見てみた新着モジュールの Jemplate。なかなか面白いです。Template-Toolkit で記述したテンプレートのテンプレート変数に JavaScript 上の JSON を展開させることができるという
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
TinyMCE JavaScript Content Editor - naoyaのはてなダイアリー:
とある友人に教えても経ったTinyMCEという WYSYWIGWYSIWYG な HTML エディタライブラリがやばそう。 JavaScript で記述された LGPL でオープンソースな クロスプラットフォームの 多言語対応もしてて 簡単に使える ライブラリ。似たようなものに htmlArea というのがあって結構昔に話題になってたんですが、導入がめんどくさかったりブラウザによってはまともに動かなかったりとか色々面倒な感がありました。TinyMCE の方はと言いますと、Installation instructions にもあるとおり、 <html> <head> <title>TinyMCE Test</title> <script type="text/javascript" src="/js/tiny_mce/tiny_mce.js"></script> <script type=
naoyaのはてなダイアリー - Perl のクロージャ
いつもお世話になってるあの人とかあの人とかが山口家の逆襲->perl-解説->クロージャというクロージャの解説ページをブックマークしてるのをきっかけに、 Perl のクロージャについて自分もちゃんと理解できてるのかというのを考えてみましたが、どうも微妙です。 クロージャについて、何でいまいち理解しきれてない感じがあるのかというと、クロージャがどういうものであるかは知ってるけど、クロージャをどういう時に使うと良いのかが具体的にあれとこれという感じで思い付かないからなのではないかと思った。 なので、Perl でクロージャを使ってる実装とかを見て、どんなときに使われるものなのかをリストアップして理解を深めてみよう..のコーナーです。 クラスにデータを保持するためのクロージャ 僕がぱっと思いついたのは Class::DBI の中で使われている Ima::DBI におけるデータベースハンドラのキャッ
Dampening, Buffering, OpenSearch, Ajax な Hack - naoyaのはてなダイアリー
ちょっと前に Six Apart の Anil Dash の blog で Web Development Trends for 2006 なんて話題があって、来年のウェブ開発トレンドはこれだ! なんてことを彼の独断でリストアップしてました。氏曰く AtomPP, XHTML, JSON, E4X, Ruby ... などなど。 このリストがほんとにトレンドになるかですが、Ruby は Rails の勢いがますます加速しているし、AtomPP は今年末に仕様が確定する他 RESTful なアプリケーション設計が注目を集めています。あと JSON が熱いのはいわずもがな...ということで結構いいところを突いてる気がします。 この中で聞きなれないれない言葉として Dampening と Buffering というのが出てきます。どちらも Rails を開発した DHH がいる 37signal
prototype.js でデザインパターン - Iterator
Ruby on Rails や Catalyst のプラグインなんかでは prototype.js という JavaScript のライブラリを使って、Ajax サポートを実現しています。prototype.js とフレームワークが必要な Ajax の JavaScript コードを吐き出してくれるので、Ruby プログラマや Perl プログラマは JavaScript の実装を意識しなくても Ajax なインタフェースが作れる、という風になっています。 こんな感じで prototype.js は Ajax な部分に注目が集まっていますが、ほかにも "Class-style OO" なフレームワークも内包してます。 JavaScript はプロトタイプベースのオブジェクト指向言語で、C++ や Java のようなクラスベースのオブジェクト指向言語とはちょっと実装が異なります。プロトタイプ
Lightweight Language Day - naoyaのはてなダイアリー
昨日はLightweight Language Day and Nightに行ってきた。夕方から用事があったので昼の部だけ。いろいろメモってきたのだけど、時間がないので簡単に。 まず、地図をみたら新宿駅下車っぽかったので、新宿から四谷区民ホールまで歩いていったらえらい遠くて大変でした。着いた頃には Language Update の何個かがすでに終わってしまっていた。でもまあ、終わってたのは awk、Curl、Gauche、Haskell あたりで、P3R は聴けたのでよしとする。あ、P3R っていうのは今僕が勝手に作った言葉で(ｗ) Perl、PHP、Python、Ruby のメジャー4大LLのことです。 PHP が 5.1 でかなり速くなるとか、実用的な面を重視しているため update も信頼性向上みたいなところが多くを占めている様子 (PEAR、PECL を分離するとか)、Perl
Perl でできてるサービス - naoyaのはてなダイアリー
長らく謎だと思っていたことが、あっさり判明した。 アマゾンのWebサイトはperl言語でできている。 Mason を使っているというオフィシャルのコメントから Amazon は Perl を使ってるんだろう、という話。Amazon のフロントエンドに Perl が使われている話は意外と知られていないもので、今日のはてなブックマーク人気エントリーにもあがってます。 実際には アマゾンの秘密──世界最大のネット書店はいかに日本で成功したか でも、Amazon のシステムの更新にはビルド作業というのが必要で、ビルドには結構時間がかかるなんていう記述も見られるので、全てが Perl ではなさそうというのは引用元記事にもある通りかなと思います。(確か Perl を使っているという記述もあったような気がする。) 僕が知ってるとこだと、以下も Perl で作られている近頃の大規模なサービスの一例かな。
Net::ECS4 ... 挫折気味 - naoyaのはてなダイアリー
amazlet.com がちょっと雑なつくりになっていてかなりリソースを無駄に使っているので、ここいらで再構成しようかなと思い、せっかくだから ECS3 から ECS4 に乗り換えてみよう、という気になりました。 それで、どうやって ECS4 をハンドリングしようかなと思ったんですが、いい機会なので ECS3 で言うところの Net::Amazon みたいにライブラリを作ってしまおうと思ったわけです。 Net::ECS4 それで、試行錯誤を繰り返しながら途中まで作ってみてはみたものの、色々問題点にぶつかりちょっと面倒な作業が多いことに気付き、息切れ中。 インタフェースは use Net::ECS4; my $ecs = Net::ECS4->new( SubscriptionId => '05E4Z6BS905VMVE919G2', AssociateTag => 'naoyadyndns
産経新聞の成果主義手取り2万円という記事を見て - naoyaのはてなダイアリー
営業成績によって増減する給与制度で、六月の手取り額が約二万二千円となった富士火災海上保険（東京）の男性社員（５２）が十五日、生存権を定めた憲法に違反するなどとして、三??五月の平均給与約二十一万九千円などの支払いを求める仮処分を東京地裁に申し立てた。 朝起きてウェブの巡回をはじめてみたところ、このニュースがはてなブックマークの人気エントリーにあがっていました。 以前JRの脱線事故が起こった際、事故現場付近にいたJR社員が救助にはいかずにそれぞれの普段通りの業務に就いた、というニュースがあったのはみなさんご存知のことかと思います。ニュースの記事内容が「救助にいかないで普通に仕事してるとは何事か」みたいな論調だったのと、事故を起こしてしまったJRという企業に対して事故に遭遇してしまったのは個人という関係もあってか、JR側が非難にさらされた。その非難の多くは感情的なものが多かった。でも後日に、こ
naoyaのはてなダイアリー - microformats って一体何だ?
にわかに盛り上がりを見せている microformats。Technorati が最近注力しているので有名で、Web 2.0 のディスカッションの中でもときおり出てくる重要な要素らしい。アルファギークな人たちも、近頃は microformats について触れることが多くなってきました。 が、僕は頭が悪いんだろうか、いまいち何のことだかよくわからなくって困ってたので、ここで少し腰を据えて、色々見て回り勉強中です。まだ細かいところがもやもやしてはいるものの、ようやくその実体が掴めて来た感じです。 「microformats とは何か?」と言われると、その答えはズバリ About microformats というエントリーに書かれているのですが、これを理解するよりまず具体例から入った方が分かりやすい。現在 microformats と呼ばれているもののうち、すでに実用段階に入っているものがありま
naoyaのはてなダイアリー - つぶやき - Web 2.0 の世界とデジタル・デバイド
Web 2.0 で重要とされる考え方は色々あって(yohei-y:weblog: REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)で図式化されて説明されているのでその辺も参照)、そのいくつかはすでに具体的に実現されているものがある。REST的な考え方、Permalink、フィードによるメタデータの syndication、Webservices API、tagging による Folksonomy、microformats、user script (Greasemonkey や Trixie、Turnabout etc..) による Content Remixing... などなど。 つらつらと眺めてみると、そのうちの幾つかをのぞき、いまのところ実現されている
「注目フィルタ」がかかったRSSの配信 - naoyaのはてなダイアリー
はてなブックマークのナビゲーションを色々改善するのを最近やっています。エントリー追加時にタグ一覧が出てくるようになった変更は、みなさんご存知かと思います。(あの機能はid:kambara君に作ってもらいました。さすがユーザーインタフェース専門家。) その一方で、一見地味なような改善として、各情報のデフォルトを「注目のユーザー一覧」にする、ということもやってきました。 ベータサービス開始当初は、注目エントリーの機能が存在しておらず、新着エントリー、人気エントリーのみの提供となっていました。そして、ブックマーク数が増えた現在は、人気エントリーよりも、時系列の要素が含まれる注目エントリーの方が、より価値の高い情報が含まれたページとして認識されるようになってきました。 そこで、 キーワード ドメイン カテゴリ をそれぞれクリックした際に表示されるエントリー一覧は、デフォルトで「注目エントリー」にな
Perl OO におけるオーバーヘッド - naoyaのはてなダイアリー
フレームワークを考えるにあたって、気になる部分のベンチマークを取ってみた。 ポイントは次の３点。 関数の呼び出し方法： Class::func() と Class->func() 形式 クラスを継承した場合のペナルティ： Class->() と SuperClass->() 連想配列への直接アクセスと、アクセサ経由のアクセス Perl における関数型の実装と OO の実装で、関数呼び出し/メソッド呼び出しでどの程度のオーバーヘッドの差があるかをベンチマークした結果。勉強になります。結果としては関数型に対して OO の方が数倍遅い、という結果。 それで、結論の方なのですが 本来なら、アプリケーションより下位にあたるライブラリ関連は、オブジェクト化されて mod_perl 上で共有されるメリットはあるかもしれないが、アプリケーションの上位にあたるフレームワークは、mod_perl 上で共有され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
