C30K問題とC60K問題 - makotanのブログ
だいぶ前にTomcatのフロントにnginx入れなかったら、入れないの？？どうして？？って質問されたのを思い出してふと書いてみる その時は「必要ないから」ってだけ答えて詳しく説明してないけどｗ 歴史 ずっと昔 Apache - Axx - Tomcat 方式 ApacheをHTTPのネットワークインタフェースとして独自プロトコルでTomcatと繋ぐ方法 ネイティブなApacheに静的ファイルを配置してTomcatは動的なファイルだけにすることで遅いTomcatを補完する方法 nginxが良かった頃 nginx - reverse proxy - Tomcat 方式 ApacheもTomcatもBlockingIOなので、代わりにnginxをフロントに配置する方法 nignxがNon BlockingIOなのでTomcatが処理本体に集中して接続処理などはnginxが担当する この辺りでNI
Thundering herd 対策の本命、 EPOLLEXCLUSIVE を試してみた : DSAS開発者の部屋
epoll を使った prefork 型アプリケーションサーバーにおける Thundering herd 対策の決定版として注目されていた EPOLLEXCLUSIVE が、 3/13 にリリースされた Linux 4.5 で導入されました。 昨年 SO_REUSEPORT というソケットオプションが登場して、 Thundering herd 対策として話題になったものの、ワーカーごとに listen キューが作られるため graceful restart するときに listen キューに入ってるリクエストを取りこぼす可能性があり利用するのが難しい状況でした。 参考: epoll の thundering herd 問題について解説しているサイト http://tech.geniee.co.jp/entry/so_reuseport http://uwsgi-docs.readthedo
CGI、マルチスレッド、シングルスレッド+イベント駆動そしてNode.js - wyukawa's diary
僕はNode.jsとはそんなに関わりはなくてshibを使っているのが唯一の接点なんだけど、http://mozaic.fm/post/99334017903/10-node-jsを聞いてたら大変に面白かったので面白かった部分について書く。 このpodcastは全部で2時間以上あって全部聞くのはなかなか辛いんだけどw 僕が面白いと思った部分はCGI -> マルチスレッド -> シングルスレッド+イベント駆動 という技術の歴史的な経緯のあたりです。 インターネットが出た当初は同時アクセス数も少ないのでCGIが一般的でリクエストがくるたびにプロセスが起動してさばくというモデルで全然問題がなかった。 それがECサイトとか出てきて同時アクセス数が増えてくるとCGIモデルが辛くなってきたので、リクエストをスレッドでさばくマルチスレッドモデルが登場した。 余談だが僕が2002年に社会人になってServl
Thousands of Threads and Blocking I/O
This document summarizes a talk about different server models using synchronous I/O (thread-per-connection) versus asynchronous I/O (NIO). The talk discusses the evolution of server designs from simple multithreaded models to NIO-based approaches. It presents arguments for both approaches but notes that benchmarks showed synchronous I/O to be faster than NIO in some cases, contradicting common bel
The C10M problem
Scalability. It's the question that drives us. It's an anomaly inherent to the programming of the matrix. It's time for servers to handle 10 million simultaneous connections, don't you think? After all, computers now have 1000 times the memory as 15 years ago when the first started handling 10 thousand connections. Today (2013), $1200 will buy you a computer with 8 cores, 64 gigabytes of RAM, 10-g
Erlang: WhatsAppを支える技術 - ワザノバ | wazanova.jp
[Video] http://vimeo.com/44312354#at=0 [Slide] http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf WhatsAppは日本でいうところのLineにあたるサービスでしょうか。このニュースによると、WhatsApp: 月間UU３億、WeChat: 月間UU2.3億、Skype: 月間UU2.8億、Line: 登録２億 (UUは発表しないんですね。。) ということですから、相当でかいですね。 昨年になりますが、Rick Reed (WhatsApp <- Yahoo! <- SGI)が、同サービスを支える、数百万ユーザの同時接続システムについて、SanFranciscoのErlangのカンファレンスで語ってます。 メッセージのトラフィ
C500k in Action at Urban Airship
Mike Herrick SVP of Product & Engineering Published on 24 Aug 2010 Like the idea of working on large scale problems? We’re always looking for talented engineers, and would love to chat with you – check it out! Building AirMail Push for Android’s Infrastructure We’ve been working to develop AirMail Push for Android, our push platform, along with a supporting server-side infrastructure that can hand
How to get C like performance in Java
Understanding how Core Java really works can help you write simpler, faster applications. OverviewJava has many areas which can be slow. However for every problem there is a solution. Many solutions/hacks require working around Java's protections but if you need low level performance it is still possible. Java makes high level programming simpler and easier at the cost of making low level programm
関数型言語と並行処理 Haskellでのネットワークプログラミング 2013.5.24 山本和彦
1 Haskell 2013.5.24 2 3 1988 B4 Sun 1992 4 Unix Magazine Unix Magazine UNIX RFC FYI (For Your Information) 5 IP PEM (Privacy Enhanced Mail) WIDE Project mh-e PEM 6 7 Unix Magazine PGP PGP 1 8 Mew (MIME) Mew Emacs Emacs XEmacs 9 Emacs Mew off Mew Emacs read-passwd gnu.org 10 IIJ KAME IIJ 11 KAME KAME WIDE BSD IPv6 IPsec Mobile IPv6 IIJ NEC BSD IPv6 IPsec Mobile IPv6 Mac IPv6 KAME 12 IETF Internet E
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
10 000 comet connections
Q: How well does the Nginx HTTP push module perform with 10 000 concurrent clients? (Ye olde C10k problem). A: Very well. About 7 kB per client and practically zero CPU load. This article describes how I performed the test, using three different hosts – my local computer, a Debian Linux server and a Mac OS X host simulating 10 000 clients. Disclaimer: This test is not intended as a realistic multi
Monoceros というPrefork型だけどC10Kの接続を捌くことができるPSGI/Plackサーバ書きました - blog.nomadscafe.jp
Monoceros というPSGI/Plackサーバ書きました https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros StarmanやStarletのようなPreforkなアプリケーションサーバでは、コネクションの維持イコールプロセスの占有なので、HTTPのKeepAliveは無効にするのが一般的ですが、負荷の高いサービスではTIME_WAIT状態のソケットが溜まったり、SYN-ACKの再送問題などあり、KeepAliveを使いたいという欲求があったりなかったりします。 Monoceros はリクエストを処理するworkerの他に、イベントドリブンで動くコネクション管理プロセスを立てて、クライアントからの接続ソケットをunix domain socketを使いプロセス間でやりとりします。待機
The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution - High Scalability -
« Sponsored Post: Dow Jones, Spotify, Evernote, Surge, Rackspace, Amazon, Booking, aiCache, Aerospike, Percona, ScaleOut, New Relic, LogicMonitor, AppDynamics, ManageEngine, Site24x7 | Main | Stuff The Internet Says On Scalability For May 10, 2013 » Now that we have the C10K concurrent connection problem licked, how do we level up and support 10 million concurrent connections? Impossible you say.
軽量スレッドブームだと思うので、そこらへんの情報をまとめてみる - 金利0無利息キャッシング – キャッシングできます - subtech
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
c10k problem memo
C10K とか, Web サーバ (あるいは Node.js みたいなフレームワーク) とか, Web システムのパフォーマンスとかを議論するときには, いかに並列処理するか (スレッドとか) と いかに IO をうまくハンドリングするか (multiplexing とかノンブロッキング・非同期とか) の知識が共通で必要になる気がするのでここを抑えておきたい. ここからイベントドリブン (libev とか) -> 実際のサーバやフレームワーク・ライブラリの実装 という風に進んでいけばいい気がする 結論 これを読むのが一番近道感がある. UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI - W.Richard Stevens Process & Thread どちらも処理の並行実施の単位 プロセスを復習すると 処理の実行単位 メモリを個別に持つ 1 つ以上
node.js と thread hog の話（１）
ここ数日、 node.js で色々と作りはじめているのだが（node.js が一番力を発揮するのは、xmpp server や、push notification server のようにソケットを開きっぱなしにして非同期通信をするケースだと思うのだが、それについては来週のメルマガで詳しく解説する）、これで思い出すのが Microsoft 時代の「"thread hog" 退治」だ。 "thread hog" とは私が作った造語で、"memory hog" （メモリをやたらと使うプログラムのこと）と同じように、thread を不必要に作るプログラムのこと。 最初に出会った thread hog は、Microsoft が作っていた proxy server だった。コネクションが１０００を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、
Linux Kernel Tuning for C500k
Urban Airship Published on 29 Sep 2010 Like the idea of working on large scale problems? We’re always looking for talented engineers, and would love to chat with you – check it out! Note: Concurrency, as defined in this article, is the same as it is for The C10k problem: concurrent clients (or sockets). At Urban Airship we recently published a blog post about scaling beyond 500,000 concurrent sock
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md