naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
はてなブックマークの裏側その後 - naoyaのはてなダイアリー
まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000
はてなブックマークカウンターと bookmark.getTotalCount - naoyaのはてなダイアリー
今日は二つほどはてなブックマークの新機能を公開しました。 http://hatena.g.hatena.ne.jp/hatenabookmark/20061004/1159941842 http://hatena.g.hatena.ne.jp/hatenabookmark/20061004/1159944160 はてなブックマークカウンター と、カウンターでも表示されてる数字を XML-RPC で取得できる API です。カウンターは早速この日記のサイドに表示させてみました。はてなダイアリーなら bcount モジュールで。 API の方ですが、告知で書いてるサンプルスクリプトで好きなサイトのブックマーク数とかを調べられます。 #!/usr/local/bin/perl use strict; use warnings; use XMLRPC::Lite; my $url = shift
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
プログラマの種類とキャリア - naoyaのはてなダイアリー
http://d.hatena.ne.jp/mkusunok/20060426/hr を読んでいろいろ考えた。 最近はてなブックマークとか見てて、優秀な人は自分がすごいことをやってるとか、努力してることに気づかないみたいな話がありましたね。例えば僕なんかはゲームがすごい好きで、ある程度つまらないゲームでも結構ずーっとやってられるみたいな感じがありますが。んなゲームするのが好きでどうすんだよ! ってそういう話じゃなくて。この感覚をときどき、プログラミングをしてたりコンピュータを触ってるとき、新しい技術について調べてるときに感じることがあるよという話。 その一方で、読みづらくて分かりづらい本を読んだり、ひたすらバグを叩いてるときとか、同じプログラミングに関することでも気分が滅入るときはたくさんある。プログラマという職業を続けられるのは、プログラミングが好きだからと思う一方で、好きだからといって
ETech 会場は Mac だらけ - naoyaのはてなダイアリー
Mac 使う人がすごい勢いで増えてるなあと最近思ってたんですが、ETech の会場にいくとびっくりします。印象では半数ぐらいが Mac な感じ。(実際にはもう少し少ないかもしれないけど、そういう印象を受ける) あと iBook よりも PowerBook の方が多い。 そりゃ ETech にくる客層はテッキーな感じなんで Mac 率が高くなるのもまあ分かるは分かるんだけどさすがに半数も Mac だとびっくりします。プレゼンテーターの人も Mac + Keynote って人が多い。このセグメントには Apple の時代が来てる、間違いない。 需要曲線的にはまだ左側の方ですが、曲線の通りにいくとこりゃ3年後はコンシューマ市場は Microsoft はやばいかもわからんね。オフィスに納品される PC とかがどうなるかってのはまた全然別の話だとは思いますが。 写真は PowerBook でプレゼン
naoyaのはてなダイアリー - 疎結合のための Web API
RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？ 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
インタフェースの話 - naoyaのはてなダイアリー
一つ前のインタフェースの話。いろいろフィードバックをいただきました。ありがとうございます。 >
3年前の自分は別人、を他のひとにも当てはめてみる。 - naoyaのはてなダイアリー
自分の3年前を思い出すとまさに別人であり、5年後のことなんてわかるはずもない、なんてことを以前にもちょっと書きました。 はてなに入社して一年半ぐらいが経ちましたが、技術はもちろんそれ以外にもその間に得た物もの相当大きくてやっぱりその時と比較して今の自分は別人だなあと思います。 これは自分だけじゃなく、周囲を取り巻く人という人すべてがそうであって、そういう風に考えるといろんなものが見えてくる。 僕は近頃「初心者」という言葉の使い方に気をつけるようにしています。 特にウェブアプリケーションを作るなんて話で議論になると「初心者」という単語が良く出てきます。「初心者にもやさしい」とか「初心者でも扱えるように」とか。でも、初心者っていうのは3年後は初心者じゃない。上級者は3年後も上級者だろうけど。そして本当に初心者である期間はほんとに短い。だから「初心者にわかりやすい」みたいなところを中心に議論を進
naoyaのはてなダイアリー - 似たようなことをやってるけど実は違うことをやってる人たち
梅田さんより10歳前後若いブロガーたちが急激な変化を予想する一方、44歳の梅田さんは一貫して、「変化は起きるが、みんなが思っているほど急激ではないだろう」という立場で語った。 僕もこのイベントにはちょこっと顔を出してみました。 なんかパネラーの人たちがはてなブックマークの話をたくさんしてて、開発者がここにいるって言うのに開発者そっちのけで色々話してて、まあ最後に開発者から一言とかで呼ばれるだろうと思ったらそんなこともなくって。おまえらいい加減にしろと憤慨しました。いや、冗談です。 個人的には第二部の SNS の話で id:umedamochio にいじられる山岸さんが面白くてしょうがなかったんですが、ここは敢えて第一部の話に触れてみよう。 この ITmedia の記事の冒頭の一文にあるように、「ネットがマスメディアを飲み込むんだ」という見方に対して梅田さんが「いやいや、そんなに簡単にはいか
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
Hacking Apache HTTP Server at Yahoo! - naoyaのはてなダイアリー
遅ればせながら Hacking Apache HTTP Server at Yahoo! を一通り読みました。これは Yahoo! のエンジニアである Michael J. Radwin 氏が昨年末の ApacheCon で喋ったときのスライド。 http://public.yahoo.com/~radwin/talks/yapache-apachecon2005.htm Yahoo! が Apache に独自に手を入れた "yapache" なる Apache を使ってるというのはときどき聞いてたんですが、具体的にどういう変更が入ってるかとかは謎のままでした。このスライドにはその辺りの話が惜しげもなく書いてあって、とても面白い。 シグナルを使わないでログをローテーションするとか、ログフォーマットを工夫してるとか、出力の HTML にホスト名などを記載しておいてサポートに役立てるとか、いろ
naoyaのはてなダイアリー - MacOSX の感想とか。
PowerBook を買った直後ぐらいに愛用していた ThinkPad が壊れて、どうしても Mac を使わなければいけない状況になったこともあって、気づけばしっかり Switch してたわたくし。ようやく MacOSX の扱いにも慣れてきて、MacOSX は良いなあと実感できるようになってきました。 何が良いのか。 まあ、色々あるんですが使い易いとかそういう事よりもやっぱり「いいもの使ってる感じ」っていうのが一番大きい気がします。何年も Windows を使ってきたもんで、まだ Windows の方が便利かなあと思う機会も時々あるんですが、もう戻る気がしないのはこの言葉にしづらい愛着があるからなんだろうなあと思うこのごろ。ターミナルで Courier-New なアンチエイリアスフォントが使えて美しいみたいな日々ヘビーに使うツールを良い感じのルック & フィールで使えるとか、そういうちょっ
lighttpd で FastCGI / CGI-Application-FastCGI-0.01 - naoyaのはてなダイアリー:
Catalyst の雛形アプリ (catalyst.pl MyApp 叩くと出る Hello World! 的なやつ) をいろんなとこで動かしてベンチとってみた。 typester さんによる Catalyst を使ったベンチマーク。Catalyst そのもののベンチマークよりも lighttpd の速さに注目。ずいぶんと速いです。 はてなでも画像サーバーなどの static なコンテンツを返すサーバーに lighttpd を使えないもんかと、ベンチを取ったりしてます。ベンチ結果では、画像ファイルとかだと Apache2 とそこまで差は出ない感じなんですが、単に画像の転送時間が支配的になってるだけかもしれないし、ちょっとトラフィックの多いところに挟んで試してみようかなと思っています。 んで、この typester さんのベンチ結果の中で興味深いのは mod_perl + Apache 1.
GNU screen いろいろまとめ。 - naoyaのはてなダイアリー:
先日人力検索で GNU screen の設定TIPSについて質問してみたところ、かなーり役立つ設定とかをたくさん教えてもらうことができました。みなさん感謝。 そんで、教えていただいた通りにカスタマイズした結果、こんな感じのスクリーンショットが撮れました。MacOSX のターミナルです。 おかげさまでかなり便利になって作業効率が上がったと思います。いろいろ教えてもらったお礼とまではいきませんが、やった設定とかをはまりどころとかも交えて紹介してみます。名付けてリバースNDOメソッド。ちなみに、知ってる人にはごく当然のことが当たり前のように書いてるので、あんまり役に立たないかもしれません。 hardstatus alwayslastline で最終行にウィンドウ一覧を表示 これは今回の質問とは直接関係ないのですが、やるとやらないとでかなり使い勝手が違うので。 hardstatus alwaysl
naoyaのはてなダイアリー - del.icio.us に関するつぶやき - その2
弾さんからツッコミをもらったので、返答しておく。 「警鐘」って、なんか小さくても堅実にやって来た町工場が大企業に札束でひっぱたかれて身売りみたいな印象があるけど、少なくとも今回のそれは違うよ。だって、どうみても始めから大企業に売りつけるために作った会社だもん。 警鐘っていうのは「ニュータイプウェブ企業は自社で売り上げ上げて食ってくあるいは IPO するとかってのは無理っぽい、みんな買収目当てでやってんだよね」って世間の人が言い始めるかもしれないよっていう点ですよ。もし、そういう人たちが言うようにこれから先のウェブ企業に買収しかゴールがないってのは、全然夢がないし、そういう意見ばかりが目につくようになってほしくない、そういう意味。 で、del.icio.us が端から買収目当ての会社だったかもしんないじゃん? っていうのはその通りだと思わせる点は弾さんが挙げてくれてる通り。 このとき Blo
del.icio.us 買収に関してのつぶやき - naoyaのはてなダイアリー
del.icio.us が Yahoo! Inc に買収されたのは、こういう新しいタイプのウェブアプリケーションを作っている企業 (もうなんとか 2.0 とかいうのはやめた) にとっては一つの朗報かなと思う。価値のあるアプリケーションを作っていれば、ちゃんと目をつけてくれる人が出てきて、ゴールを用意してくれるという意味で。 一方で、警鐘でもあると思う。Bloglines、Flickr、del.icio.us のような、注目を集める新しい企業(サービス)のゴールが、やっぱり買収されるしかないんじゃないの? という見方に拍車がかかりそうだから。そして、買収されてゴールを迎えられるのは Bloglines、Flickr や del.icio.us のような、世界でも指折りのアプリケーションじゃないといけない。華々しいアーティストの成功の裏には、膨大な数の屍があるというのと同じ話で。 個人的には、
del.icio.us has joined the Yahoo! family - naoyaのはてなダイアリー
We're proud to announce that del.icio.us has joined the Yahoo! family. Together we'll continue to improve how people discover, remember and share on the Internet, with a big emphasis on the power of community. We're excited to be working with the Yahoo! Search team - they definitely get social systems and their potential to change the web. (We're also excited to be joining our fraternal twin Flick
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
