Requests per second vs. number of concurrent connections? Lwan was until recently just a personal research effort that focused mostly on building a solid infrastructure for a lightweight and speedy web server. With its low disk and memory footprints, it's suitable to be used from embedded devices to robust servers. Both static and dynamic content can be served, as it can also be used as a library.
http serverに関するyassのブックマーク (19)
-
yass 2017/05/27
-
Apache チューニング Tips | Carpe Diem
先日、Web サーバ勉強会 #2 が開かれました。内容は、Apache のチューニングということで、参加したかったのですが、他の予定があって参加できませんでした。 そこで、僕が個人的に行っている Apache のチューニングを紹介したいと思います。最初、スライドで作成しようかと思ったのですが、ブログにまとめたほうがよさそうなのでブログにまとめていきます。 まず、大前提として Apache をチューニングするうえで、大事なことはその Apache が提供する Web サービスの種類のよって大きくチューニングする内容が異なるということです。例えば、動画・写真共有サービスと株価情報のサービスを比較すると、当然のことながら大きくサービスの内容が異なりますし、HTTP レベルでみるとクライアントからのリクエスト数、データサイズ、などがかなり違ってきます。 ですので、まずは自分が扱っているウェブサービ
-
HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta
-
CS193H – High Performance Web Sites
スタンフォード大学で、CS193H – High Performance Web Sites というタイトルの講義が行われた。そのときのプレゼンテーション資料が、公開されていた。講義は、9/22 から 12/5 まで行われて、おもに次のような内容だったようだ。講義タイトルを翻訳してみた。 9/22: 導入 – Introduction 9/24: フロントエンド側のパフォーマンスの重要性について – The Importance of Frontend Performance 9/26: HTTP ウェブサイトの 100 のパフォーマンスプロファイル – HTTP Web 100 Performance Profile 9/26: 開かれたウェブのパフォーマンス挑戦 – Performance Challenges for the Open Web 10/1: フロントエンドカンフー –
-
-
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
-
thttpd - Wikipedia
thttpd (tiny/turbo/throttling HTTP server) はオープンソースのWebサーバで、シンプルで使用メモリが少なく高速に動作するように設計されている。開発はACME Laboratories。より高機能なWebサーバの単純置き換えとして使えるが、静的データへの大量のリクエストを扱うのにとても適している。例えば、画像置き場サーバ。 最初の文字の"t" は tiny、turbo、throttling を表している。 thttpd はApache HTTP Server を初めとする他のオープンソースのWebサーバソフトウェアにはない帯域幅調整機能を持っている（Apacheではアドインモジュールで帯域幅調整を使うこともできる）。 この機能を使うと、ある特定のファイルタイプを持つファイルの最大転送速度を制限することができる。 例えば、サーバ管理者はJPEG画像ファ
-
.htaccess ファイルを簡単作成「.htaccess Editor」
リダイレクト Fromにサイトパスを入力、ToにURLを入力 301 Moved Permanently 恒久的に移動 From: To: From: To: From: To: 302 Moved Temporarily 一時的に移動 From: To: From: To: From: To:
-
Lighttpd 1.5 系がスゴイらしい
はてブで lighty のブログがあることを知ってブログを見てみました。lighty の中の人が書いてます。 ナント、lighty 1.5 系が pre release されているではありませんか！ なんでも、1.5 系は いままでより 80% のスループット向上が見込めると書かれています。激速の lighty が更に高速になるってわけですよ。Σ(ﾟДﾟ； Using Async IO allows lighttpd it overlap file-operations. We send a IO-request for the file and get notified when it is ready. Instead of waiting for the file (as in the normal sendfile()) and blocking the server, we ca
-
Milano::Monolog: mod_rewriteでサーバーの負荷が高いときだけリダイレクトする
mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースを食いつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー
-
オープンソースの高速Webサーバー「TUX」の実力
図5●プラットフォームの違いによる，コネクション確立の所要時間の差異<BR>TCPコネクションが確立するまでの時間を調べた。TUX 3.2はチューニング前後の数値にそれほど大きな違いはなく，比較的安定している。一方でApacheは標準設定時に扱えるプロセス/スレッド数が小さいため，Fedora Core 2.0とApache 2.0の組み合わせにおいてコネクション確立に要した最大時間が3009ミリ秒に達した。チューニングによって扱えるコネクション数を増やしたApacheでは，コネクション確立までの平均時間と最大時間が，いずれもTUX 3.2の性能をしのいでいる カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX Web Server」（以下，TUX）の性能を，現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で，TUX 3.2はApache
-
ウォーターマーク MOONGIFT
一括透かし 写真や商品画像をコピーされてお困りのあなた。マークを入れて守るのはどうだろう。 一括透かし ECサイトなどで、商品画像をそのまま流用されたり、写真を勝手に使われたりすると言った問題は多い。コンピュータ上では素材のコピーなどは容易なので、対抗策が必要だ。 その一つとして、画像に自分のマークを入れてしまう事がある。だが、一つの一つの画像にそんな手間をかけられるだろうか。 今回紹介するフリーウェアはウォーターマーク、画像に透かしを入れられるソフトウェアだ。 対応画像形式はJPEG/BMP/TIFF/PNGとなっている。透かしに使う画像は透過GIFを利用する。画像の入ったフォルダと出力先、GIF画像を指定すればOKだ。 透かしの入れる場所も中央、または上下左右の組み合わせで入れられる。透明度も指定可能だ。出力時の画像形式や、指定幅での縮小機能も備えている。 自社や自分で撮った画像は財産
-
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Contact Lens song lyrics fashion trends High Speed Internet Migraine Pain Relief Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
-
sanonosa システム管理コラム集: Apacheの代わりに高速WEBサーバTUXを使おう
sanonosa システム管理コラム集 最近まで某有名サイトのシステム管理（サーバ管理、ネットワーク管理、システム構築など）をやっていました。大規模サイトの運営ノウハウってあまり公開されていないものですから日々試行錯誤しながらノウハウを溜めています。そんなノウハウを眠らせておくのももったいないですからこの場で公開してみたいと思います（企業秘密のもの以外）。リクエストや質問等大歓迎です。
-
esehttpd プロジェクト日本語トップページ - OSDN
esehttpdはLinux上で動作するwebサーバ(HTTPサーバ)です。realtime signals とノンブロッキングIOを使った高速・スケーラブルな実装、OpenSSLによるHTTPSの サポート、rubyスクリプトの直接実行、サーバ自身がchroot可能、などの特徴があります。 ダウンロード 最新リリース esehttpd esehttpd-0.309 (日付: 2004-02-03) esehttpd esehttpd-0.308 (日付: 2003-09-29) esehttpd esehttpd-0.305 (日付: 2002-04-11) esehttpd esehttpd-0.304 (日付: 2002-04-10)
-
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
-
cyano: 30万個ぐらいの静的ファイルを配信するサーバーの選び方
naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 弊社の画像配信サーバーには、平均10kbぐらい（たぶん）の画像が30万個ぐらいあって、それをDell PowerEdge 1750+lighttpdを使って配信してます。 以前は搭載メモリ1GBのサーバーを使っていたのですが、その時のvmstatがこのような感じ。 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b sw
-
-
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました