MarkeZine併載コラム ウェブマーケッター向けのオンラインマガジンMarkeZine(マーケジン)より、アレクサの解説をしてほしいという依頼を受けた。アレクサについては面白い情報が取れるものの、情報不足や誤解もいろいろとあるようなので頑張って書いていこうと思う。 当ブログでも同日併載する条件で引き受けたので、元原稿をベースにしたものをこちらでも掲載していく。Markezine側の記事では図表を作っていただいたり、プロの編集の手が入っているので、よりわかりやすいのではと思う。 アレクサ(Alexa)とは何か アレクサ・インターネット(Alexa Internet, Inc. 以下「アレクサ」)は、オンライン書店世界一のアマゾン・ドットコム(Amazon.com)が1999年に買収した子会社で、ウェブサイトのアクセス数を調査・統計することを事業の一つにしている企業です。 ネット以外の世界

Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに

昨晩はライブドアで開催されたテクノロジーセミナーで軽くはてなのシステムや開発体制についてしゃべってきました。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/061214livedoor_hatena.ppt (ppt, 286k) 昨晩の感想、資料を読んでの感想など、トラックバックでお待ちしております。

mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースを食いつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー

イーツリーズ・ジャパンは，専用LSIを用いたハードウエア処理によって，高さ1.5Uのきょう体1台で50万接続まで可能なWebサーバー専用装置「freeocean」を，2006年7月中旬に出荷する。狙いは「負荷分散装置と複数のWebサーバーを組み合わせたシステム全体を1台で置き換える」（イーツリーズ・ジャパン）こと。価格は機能をWebサーバーに限定し同時接続3万2768コネクションまで可能なエントリ機種が400万円（税別），キャッシュ機能を備えた機種が600万円（税別）。販売目標は今期300台。 freeoceanは，HTTP，TCP/IP，イーサネットなどWebサーバーの機能に必要な最低限のプロトコルをFPGA（Field Programmable Gate Array）で実現したWebサーバー専用装置である。ハードウエアによるHTTPサーバー機能に加え，Perl言語処理系やServlet

ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増

１年ほど前からWEBサービスの内部アーキテクチャを公開する事例が増えてきた. はてな、イー・マーキュリー共同勉強会 WEB+DB PRESS ライブドア構築ノウハウ大公開 U.S Yahoo!のTechTalk こういう試みは面白いので,ガンガンやってほしいなぁと思う.ただ自分としては 一方的に情報を受け取るのみでこちらからお返しができないことに多少引け目を感じていた. 個人的には自分が得てきた経験や知識をBlogとかに書きたいんだけど, あまりに具体的なことやコアアーキテクチャに関わる部分はいろいろ 会社的に問題ありそうなのでどうにも書けなさそうと考えている. 実際のところこういうジレンマに陥ってる人は多いのかなぁと思う.たいていの 内部アーキテクチャなどをバラしてるBlogは書いてる人が社長とかCTOとかだったり, 会社がそういうのに寛容なケースのみで,一般の社員が書くのはどうにもまず

このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。

id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー　きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン

「コネクションプーリング都市伝説」という単語がある.かいつまんでいうと 「コネクションプールって一般的に速いと言われているけど,クライアントが 多くなると接続維持のコストが大きくなるから今となっては速くないんじゃね?」 というものだ. WEB+DB PRESS vol.33でnipotanさんの中の人が書いてた記事が発端だと思われる. あとこんなエントリもあった. hori-uchi.com コネクションプーリング都市伝説は正しそう またちょっと古いねたですが、WEB+DB PRESS vol.33でnipotanさんが書いてたコネクションプーリング都市伝説を読んだ時、ほんとのところどっちが速いのかってのをabでベンチマークをとってみました。 (snip) これ以外にもいくつかパスを替えてベンチマークをとったところ、いずれも若干ですがプーリングしないほうが早かったので、現在はプーリングしな

ロゴや.cssのように滅多に更新されないデータがあったとします。サイトにアクセスする度にWEBブラウザーがこういったデータを毎回読み込むようになっているとネットワーク帯域の無駄遣いですし、レスポンスも遅くなります。そこで今回はHTTPレスポンスヘッダーを書き換えてそれらのデータをWEBブラウザーのキャッシュに残るようにする方法を記してみたいと思います。 【基礎知識編】 キャッシュコントロールを考える際、知っておくべきHTTPレスポンスヘッダーは４つ。Cache-Control、Pragma、Expires、及びETagである。細かい話しは省略するので次のサイトを見ておいてください。 事例に学ぶWebシステム開発のワンポイント（12） 今回はETagは無条件削除、Cache-ControlだけコントロールするとしてPragmaとExpiresは対象外とします。 【Apacheでの設定編】 a