こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
11/3に開催された #isucon2 に、隣の席の @pandax381 と一緒に、チーム双龍として参加してきました。 結果は惨敗だったのですが、そのレポートを書く前に、 #isucon2 で使う予定だった秘密兵器 recaro について紹介します。 recaro とは recaro はカーネル空間で動く httpd + memcached サーバーです。 httpd サーバーは @pandax381 が作成した tkhttpd で、 memcached は kmemcached というプロジェクトが 未完成のまま放置されていたのを見つけて、私がデバッグ＆高性能化したものです。 (KLab/kmemcached) 通常のnginx+memcachedだと ネットワーク <- TCP/IP ]-> nginx <-[ TCP/IP ]-> Memcached ([] はシステムコール) と
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
14:30 | Keep-Alive on / off に関する文献の多くが曖昧であることが気になっていたので、まとめてみました。Apacheのドキュメントから、Keep-Aliveの説明を拝借しますと、HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、複数のリクエストが同じTCPの接続で送られる、長時間持続する HTTP セッションを提供します。つまり、Keep-Aliveは、『TCP 3ウェイハンドシェイクの節約』であるという点を理解しなければなりません。たいていの文献は『画像やCSSが多いサイトでは、接続を使い回すことにより無駄遣いをなくす』という説明をしていますが、この接続を使い回すという表現も曖昧な気がします。何となく分かった気になってしまう人も多いのではないでしょうか。それでは、まずは以下のようなhttpd.confで、Apacheの動
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
クリティカルスピードは〜のオープンソース・ソフトウェア。高速なレスポンスを行うWebサーバは誰しもが願う所だ。Googleがあれだけ大きく成長したのは検索のアルゴリズムはもちろんのこと、高速なレスポンスにも一因があったと思われる。欲しい情報がすぐに手に入るというのはとても気分がいい。 表示が速い！ Webサーバで高速化を行うための手法は幾つか存在する。並列化したり、サーバのスペックを上げたり、ネットワークを強化すると言った方法の他、システム側でも対応できるものがある。その一つ、高速配信サーバのクリティカルスピードを紹介しよう。 クリティカルスピードの最大の特徴はKVS（キー・バリュー・ストア）をWebサーバとして使っていることだ。KVSとしてTokyoTyrantを採用しているが、今後はLuxIO、kumofs、ROMAといった他のKVSにも対応していくとのこと。WebサーバはPlack/
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
最近はルータやファイアウォールなどの組み込み系OSを必要とする場面でもWebブラウザベースで管理ができるようになっている。そのような環境のWebサーバは限られたリソースを効率的に利用できるものが求められる。その一つにAppwebがあった。 軽量かつ十分な機能を備えたWebサーバ Appwebは元々組み込み系向けのWebサーバとしてスタートしたようだが、機能の拡充に伴って徐々に一般的なWebサーバへと進化しているようだ。 今回紹介するオープンソース・ソフトウェアはAppweb、軽量かつ多機能なWebサーバだ。 Appwebの特徴をあげるとざっと次のようになる。1秒間あたりのリクエストは4,500以上、マルチCPU対応、HTTP1.1のフルサポート、バーチャルホスト、アクセス/エラーログ、Apache似の設定ファイル、800キロ程度のフットプリント、SSLサポート、Basic/ダイジェスト認証
これは非常に面白い。これまでにもiPhoneをサーバ化するソフトウェアはいくつか存在していた。だが、その目的はWebDAVのようなファイルストレージ系や、プラットフォームを楽しむためのものが多かった。 あなたのiPhoneがデータサーバに！ だがServersMan@iPhoneは違う。外部からアクセスできる、実用的なiPhoneソフトウェアを提供するのだ。 今回紹介するフリーウェアはServersMan@iPhone、iPhoneをWebサーバ＆ストレージサーバ化するソフトウェアだ。 ServersMan@iPhoneをインストールし、ServersManにユーザ登録すると、ServersMan@iPhoneのサービス上に一意のアドレスが割り当てられる。他のPCなどからここにアクセスするとServersManを通じて自分のiPhoneにアクセスできる。 ドキュメントビューワー Webサー
2005年春、2007年春に猛威を振るったSQLインジェクション（※注1）の検知数が、2008年の3月上旬から当時の何倍もの規模にまで増えてきた（図1）。正直なところSQLインジェクションは「過去の遺物」であり、ほとんどのサイト運営者が何らかの手を打ち、もう絶滅したと思われていたが、現在も被害に遭うサイトは後を絶たない（図2）。 ※注1 第三者がWebアプリケーションなどのセキュリティ上の脆弱性を悪用してデータベースの不正な操作を可能とする攻撃手法 図1●JSOC（ラックセキュリティ監視センター）で検知したSQLインジェクションの件数 図2●被害サイトは予想以上（Googleの検査結果）《クリックで拡大》 ここではWebアプリケーション（以下、Webアプリ）の脆弱性対策の話が中心であるため、攻撃の詳細にまでは触れないが、一連の攻撃で厄介だったのは、攻撃コードが難読化されていたことである（図
普通の帯域節約術としては、mod_deflateでdeflate圧縮するとか、CSSやJSファイルのHTTPレスポンスヘッダにLast-ModifiedやEtagを追加しておいて、ブラウザがHTTPリクエストヘッダにIf-Modified-SinceやIf-None-Matchを付加するようにし、コンテンツが変更されていなかったら304 Not Modifiedを返すという方法を取るかと思います。 しかし、HTTPサーバーはコンテンツの数だけ304 Not Modifiedを返さないといけないため、その分帯域を消費しますし、またCSSや画像などのパーツの304 Not Modifiedが返ってくるまで、そのパーツのレンダリングが行えないという問題があります（つまり体感速度に影響します）。 今回紹介するのはExpiresヘッダやCache-Control: max-age=31536000を
RailsのWebサーバとしては、Mongrelが最も良く使われているだろう。最近ではmod_railsも人気になってきている。Mongrelは優れたWebサーバではあるが、実際の運用時にはプロキシの設定などが面倒に感じられることがある。 起動しているところ そんな中、プロキシの設定が不要なWebサーバが登場した。 今回紹介するオープンソース・ソフトウェアはRUgD、Rails専用の高速Webサーバだ。 RUgDはCで作られたWebサーバで、そのために高速であることを謳っている。Apache側の設定はプロキシではなく、mod_rewriteのレベルで行うようになっている。ポートは一つ（例えば8017）だけで、RUgDがバランシングを行うようになっている。 コマンドラインベースでワーカーの数を指定するだけで動かせるのが簡単で良い。現在開発続行中で、HTTPパーサが90%、メモリ監視が未開発と
と言いつつ、自分ではMongrel使ってない（主にlighttpd）のですが、 RailsChatでshachiさん、くまくまーのmaihaさん、笹田さん、のりおさんと話してた時に出てきた、最近のWebサーバのメモ。 thin 軽量で高速らしい。 Ebb libevとかを使っていてthinより速いらしい。 小さいファイルが弱点だったが、最近克服されたらしい。 swiftply Webサーバではない。プロクシフレームワーク。 (See also Swiftiplyのアーキテクチャとベンチマーク) あとで試す。 話は変わりますが、上述のプログラムの大半の実装はCで書かれていて、 インターフェイスの部分だけRubyで実装されている感じのものが 多いですね。これこそがRubyの真骨頂だと思う。 いろんな言語を使ってきたけれど、 最近はCとRubyの組み合わせが良い感じです。 C言語用の高性能プリプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
