ゆーすけべー日記: YourAVHost その後
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
Flickr開発者が語るネットサービスの高速化方法
Web2.0としてくくられるタイプの各種ネットサービス、いわゆるウェブアプリは以前とは比較にならないほど動的生成されるものが多く、結果としてものすごい負荷をシステムにかけるわけです。 というわけで、海外におけるデジカメ画像共有サービスの代表的なものである「Flickr」の開発者がJavaScriptを高速化する手法について解説しています。 Vitamin Features >> Serving JavaScript Fast 手順を分割して簡単にしてみたり、キャッシュを使ったり、転送量を圧縮して帯域を節約したりいろいろあるようです。なお、GIGAZINEはキャッシュシステムを採用して有効活用することで負荷を現在、当初の12分の1に抑えています。 また、こっちはリバースプロキシによる高速化手法。 ViSolve.com - Squid Support Service Apacheのモジュール
livedoor Techブログ : nowaのサーバ構成
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
Milano::Monolog: mod_rewriteでサーバーの負荷が高いときだけリダイレクトする
mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースを食いつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー
ウノウラボ Unoh Labs: PHPで書かれたwebサービスを高速化する
尾藤正人です。 アクセス数の多いコンシューマ向けの web サービスは、処理速度がかなり重要になってきます。 応答速度が遅いと使用しているユーザにとってストレスになりますし、 処理に時間がかかればサーバに対する負荷も高くなります(厳密に言うと違う)。 そこでウノウではいろいろな工夫をして処理速度の高速化を行っています。 一口に高速化といってもいろいろな要素がありますが、大きく分けて3つの段階があります。 ・ハードウェアによる高速化 ・ソフトウェアによる高速化 ・プログラムの工夫による高速化 しかし、これら3つは独立ではなく、互いに影響しあっているので完全に分けて考えることはできません。 それぞれがどのような部分に影響を与えているのか、ちゃんと理解してチューニングすることが大事です。 ただし、高速化するときに忘れていけないのが、高可用性です。 いくら高速に動作しても安定して動作し
Kazuho@Cybozu Labs: キャッシュの上手な使い方
« C-0.05 | メイン | cygwin + mod_perl » 2006年02月08日 キャッシュの上手な使い方 キャッシュといっても、ウェブブラウザやウェブプロキシのキャッシュのことです。 ・Internet Explorer のキャッシュの動作 Internet Explorer は、同一ウィンドウ内で複数回同じウェブページを読み込む場合、２回目以降はキャッシュのデータを使用します (デフォルト設定の場合、 Last-Modified または Expires ヘッダがついている場合のみ)。 つまり、同じウィンドウの中で、 ページA を読み、次にページB を読み、そしてページA を再び読み込むようなケースでは、２回目にページ A を表示する際にはキャッシュのデータが使用され、ウェブサーバへの再問い合わせは行われません。 また、 Last-Modified ヘッダと Expire
HTTP用負荷ツールいろいろ:phpspot開発日誌
「オープンソース戦略により、無償で使えるようになった負荷テストツール」によるとWebLoadという商用のHTTP負荷計測ツールが無料で使えるようになったとのこと。 そこで、いろいろとある負荷計測ツールをまとめてみました。 ab(ApacheBench) - Apacheに付属の負荷計測ツール ＠IT：Apacheパフォーマンス・チューニングのポイント（2/2） JMeter - Javaで書かれた負荷計測ツール JMeter(高機能/フリーなテストツール)第1回：JMeterの基本 Microsoft Web Application Stress Tool - Microsoft提供のGUIによる負荷計測ツール WASTを使い倒そう！（TOP） WebLoad - 今回紹介された WebLoad オープンソース戦略により、無償で使えるようになった負荷テストツール どれもメジャーなものですが
GIGAZINEが20日（土）から21日（日）にかけて新サーバに移転します
サーバのカスタマイズで乗り切る限界を突破してしまったため、GIGAZINEは今から新サーバに移転します。新サーバ移転後、何か不具合などがある場合には臨時用のこちらのメールフォームからご連絡いただければ助かります。 というわけで以下、旧サーバと新サーバの設定などについて。サーバのカスタマイズに興味のある人向けです。 まず旧サーバは「Dell PowerEdge 850」を利用しており、以下のようなスペックです。よくありがちな構成。 ◆旧GIGAZINE.NETサーバ CPU：Intel PentiumD 930 HDD：73GB(SCSI RAID1) メモリ：2GB ネットワーク：2Mbps OS：Red Hat Enterprise Linux ES3 これが以下のようなスペックの「NEC Express5800 120GR-1c」になります。これもありがちな構成。 ◆新GIGAZINE
blog.katsuma.tv
もう、いろんなニュースサイトで言われていますが、 Yahooからページパフォーマンス計測ツールの「YSlow for Firebug」が リリースされました。Firebugをインストールしている上で、YSlowをインストールすると、Webサイトの高速化を行うためのポイントと、 現状についてのポイント表示を行ってくれます。 これ、実際に試してみるとよく分かるのですが、いかに工夫をしていないサイトは、改善の余地があり余っているか。。 ほんと身を引き締められます。ちなみにYSlowでは次の項目をポイントに挙げています。 Make Fewer HTTP Requests Use a Content Delivery Network Add an Expires Header Gzip Components Put CSS at the Top Move Scripts to the Bottom
Apacheパフォーマンス・チューニングのポイント
現状の測定（ベンチマーク）と結果の着眼点 ここからはApacheに着目して、パフォーマンス・チューニングのための準備を行う。チューニングするに当たって、まず現状を十分に分析し、具体的な目標を定めることから始めたい。目標をどれだけ具体化するかはともかくとしても、現状を数値的に知りもせずに、漠然と「遅い遅い」と騒いでいても仕方がない。 現状を数値的にとらえるにはツールが必要となる。いわゆるベンチマーク・ツールだ。Apacheには、標準で「ab」（Apache Bench）というツールが付属している。abの構文は、
ブラウザキャッシュでパフォーマンス向上
キャッシュ制御の方法 サーバサイドからキャッシュを制御するには、以下の2つの方法がある。 HTTPヘッダによる制御 METAタグによる制御 まずは、これらがどのようなものか、軽くおさらいしておく。 ■HTTPヘッダによる制御 HTTPプロトコルでは、HTTPヘッダにさまざまな情報を格納することができる。そのうちいくつかの情報は、キャッシュ制御のためのヘッダである。リクエスト（クライアント→サーバ）用のものと、レスポンス（サーバ→クライアント）用、リクエスト／レスポンス共通のものが存在する。 ■リクエスト用 If-Modified-Since 日時を指定する。指定した日時より新しいコンテンツの場合のみデータを返却するようにサーバに指示する。ローカルキャッシュの最新確認に使用される If-None-Match 指定したエンティティタグに一致しない場合のみコンテンツを返却するようにサーバに指示す
prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリー
Catalyst を POE で動かす Engine の Catalyst::Engine::HTTP::POE という実装が CPAN にあります。"Single-threaded multi-tasking Catalyst engine " だそうです。"Single-threaded" と言いつつも実装を覗いてみると環境変数 CATALYST_POE_MAX_PROC を 1 よりも大きく設定することで prefork する実装になってます。POEシングルスレッドではアプリケーション内で発生するブロックを避けることが難しいのでそのための実装じゃないかなと思います。 ところでこの Catalyst POE エンジン、prefork の実装はどのように行っているかというと POE から prefork と名の付いたイベントが発生するとおもむろに子プロセスを生成する、というのもの。複数の
selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理
mod_deflateによるコンテンツの圧縮転送
サーバのマシン性能は十分でも、コンテンツの転送時間がボトルネックとなってパフォーマンスが出ない場合がある。このようなときの対処法として、コンテンツの圧縮転送がある。（編集部） 前回に引き続き、Apacheのパフォーマンスチューニングについて解説します。今回はナローバンドで効果を上げる、コンテンツ圧縮機能を取り上げます。 回線のボトルネック解消 ブロードバンドが広く普及したとはいえ、携帯インフラなど依然ナローバンドが主流の分野もあります。そして、Webサーバ自身のパフォーマンスよりも、回線のボトルネックがレスポンスに大きく影響を及ぼすことがあります。例えば、ダイヤルアップで多くのユーザーがApacheに接続した場合、1つの接続が占有するCPU時間が長くなるため、同時接続数が増大する傾向にあります。 このような場合は、限られた回線帯域を有効に利用するために、送信データの圧縮転送で状況の改善を図
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
[_11_Install] intel compiler で Apache が 400% 高速化
「無料で30%のパフォーマンスUP!! - intel compiler」でも書いた intel compiler ですが、apache1.3.33 + mod_perl 1.29 を再構築してみました。apache bench で速度を測ってみたら、ナント 400% も高速化していました。?(￣□￣;)ﾅﾝﾄ!! 本当かぁ？？と思って数回試してみましたが、結果は同じでした。スゴイ！ 以下、インストールメモとapache bench のログです。 mv /usr/bin/gcc /usr/bin/gcc.bk ln -s /opt/intel_cc_80/bin/icc /usr/bin/gcc mkdir /usr/local/src/icc cd /usr/local/src/icc wget http://www.meisei-u.ac.jp/mirror/apache/dist/h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM LAMP システムを調整する、第 1 回: LAMP アーキテクチャー・・ - Japan
ヽ( ・∀・)ノくまくまー(2007-08-20)