TOP＞システム開発＞ はじめに

事例編〜Web 2.0サービスの中を見せます 第４回：Backend Evolution（後編） 著者：はてな  伊藤 直也   2006/10/25

1   2  次のページ

はじめに

前回は「リバースproxyとは」と「Webサーバーのメモリ使用率」について解説しました。今回は前回の続きとして、「HTTPのKeepAlive」と「リバースproxyの構築」について解説していきます。

HTTPのKeepAlive

話は変わって、KeepAliveです。    1つのWebページをブラウザーが表示するにあたっては、htmlに加えてページ中に配置された複数の画像やスクリプトファイル、つまり複数のドキュメントをサーバーからダウンロードする必要があります。    この複数のリクエストを取得するのに、サーバーとクライアントの間で複数のコネクションを張ってやりとりするのは効率が良くありません。    サーバー側でKeepAlive設定が有効になっている場合、クライアントは、1つ目のドキュメントのダウンロードが完了したあとも接続を維持します。これにより必要なコンテンツを1つのコネクションで取得できるようになり、クライアントから見てもサーバーから見ても、速度やリソース消費面でのパフォーマンスが向上します。    しかし、メモリ使用率の高いアプリケーションサーバーでKeepAliveが有効になっている場合に、ちょっとした弊害があります。    アプリケーションサーバーはメモリを食うので、あまりたくさんのプロセスは立ち上げず、1つのサーバープロセスで次々とクライアントからの処理をさばいてしまいたい。    しかし、KeepAliveが有効な環境ではクライアントがサーバープロセスを一定時間占有してしまうため、同時にアクセスが来た場合余計にプロセスを生成しなければいけなくなります。すると更にメモリが必要になり…と悪循環が発生するのです。    そこで、KeepAliveでクライアントとの接続を維持するのはプロセスをたくさん生成しても苦ではないリバースproxyで行い、ダイナミックコンテンツを生成するアプリケーションサーバー側ではKeepAliveをオフにし、1リクエストに対するサーバープロセス占有時間を最小限に留めるというテクニックを使います。    このためにもリバースproxyが必要になるというわけです。

1   2  次のページ

著者プロフィール 株式会社はてな  伊藤 直也 取締役最高技術責任者 ブログサービスやソーシャルブックマークなど、はてなの各種サービスの企画、開発を行う。著書に「BlogHacks」（オライリージャパン刊）。「続・初めてのPerl」(オライリージャパン）、「Perl救命病棟」(翔泳社刊）では監訳を務めた。

INDEX 第4回：Backend Evolution（後編） はじめに   リバースproxyの構築

事例編〜Web 2.0サービスの中を見せます 第1回 Inside Hatena Bookmark 第2回 はてなフレームワークとPerlとシステム負荷 第3回 Backend Evolution（前編） 第4回 Backend Evolution（後編） 第5回 サーバの追加とロードバランシング 第6回 データベースの負荷分散とまとめ