はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
感想: イベントVs.スレッドをhigh-conccurencyサーバを対象に して真面目に考え直してみた論文。
Rob von Behren, Jeremy Condit and Eric Brewer (UCB) Why Events Are A Bad Idea (for high-concurrency servers) Proceedings of HotOS 03, May 2003. 感想: イベントVs.スレッドをhigh-conccurencyサーバを対象に して真面目に考え直してみた論文。 Abstract イベントモデルは high-concurrency システムでは良いとされて きたが、それは間違いだ! (筆者らの信じるところによれば) イベントの良い点(高い並列性、低いオーバヘッド、シンプルな 並列モデル)などはスレッドでも達成できる。さらに、スレッドの 方がよりシンプルで自然なモデルでプログラムを書ける。 スレッドの弱さは本質的なものではなくスレッドパッケージの実装
常駐型サーバープログラムのデバッグ手法
BOOK: WEB+DB Press TITLE: 常駐型サーバーのデバッグ手法(ドラフト版) AUTHOR: (株)プリファードインフラストラクチャー 太田一樹 ＊注: この文章はWEB+DB PRESS Vol.48に掲載された記事のドラフト版です はじめに 今回はデバッグ関連特集ということで、常駐型サーバープログラムを作成する際のハマりどころやそれに対する解析方法・解析ツール・対策を、実際の経験を交えながら紹介したいと思います。 筆者は(株)プリファードインフラストラクチャーでインメモリ分散検索エンジン「Sedue (セデュー)」を開発しています。モバイル向け検索エンジン「エフルート」や、2008/11/6にリニューアルされました「はてなブックマーク2」などの検索バックエンドとして使われております。 この検索エンジンはいくつかの常駐型サーバープログラムから構成されており
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
エッジトリガ (epoll) の話 - id:kazuhookuのメモ置き場
エッジトリガのメリットとしては、「データが貯まった状態で処理を後回ししても起こされない」というのもあるみたいだけど、これはEPOLLONESHOTというオプションを使うとレベルトリガでも実現可能。 epollであえてエッジトリガを使うとすれば、「ノンブロッキングI/Oでいつも最後までデータを読んでるから、レベルトリガはただの無駄だよねー」とかいうときの気持ちの問題ではなかろうか。 http://d.hatena.ne.jp/nishidakeisuke/20080703/p1 エッジトリガとレベルトリガで、コーディングの差が大きくなるのは、むしろデータを書く場合なんじゃないのかなぁ。レベルトリガだと、 send(2) が EAGAIN を返したら epoll に fd を登録 アプリケーション側のバッファが空になったら、epoll から fd を削除 というコードを書かないといけない (と
High-Performance Server Architecture
Introduction The purpose of this document is to share some ideas that I've developed over the years about how to develop a certain kind of application for which the term "server" is only a weak approximation. More accurately, I'll be writing about a broad class of programs that are designed to handle very large numbers of discrete messages or requests per second. Network servers most commonly fit
死滅病棟: Re: マルチコア時代のサーバ設計について
2008年5月9日 Re: マルチコア時代のサーバ設計について RTMP においてビデオストリームをどのようにマルチコアでスケールさせながら配信すれば良いかについてだらだら考えたいたところに丁度ぴったりな記事が出てきてくれた。ありがたい。 今回実装しようとしているもので必要とされる処理は CPU 使用率が瞬間的に上がる可能性があり、かつパケットの配送が一時的であれ大きく遅れるとあまりよろしくなく、複数プロセスに分割することもできなかったのでこういった情報を必要としていた。 スレッドプールでは駄目なのか？ もう一つ疑問。アクティブスレッド数を制限するなら、単純にスレッドプールを使うんじゃ駄目なんだろうか？なぜわざわざセマフォを使うのか？ここの理由がいまいちわからない。 俺もセマフォを使う意味はよくわからない。前にネトゲサーバーを作った時はスレッドプールにしていて、スレッドローカルなデータの消
マルチコア時代のサーバ設計について - Happy Hacking Diary
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
2000万個のプロセスを動かすための並列モデル - 最速配信研究会(@yamaz)
# タイトルは煽りです. 今週末ドリコムさんでCometとその周辺技術（イベント処理、Erlangなどなど）に関する勉強会が行われるので,ここ最近つらつら考えたり調べたりしてたことを外に出します.yamazはErlangの文法とかにはあまり興味がなく,2000万のプロセスが並列実行できるというそのモデルに興味があるので,とりあえずそこについて. なおいつもにも増して適当なこと書いてるので,適宜マユツバでお願いします.ツッコミ大歓迎. Erlangは1マシンで2000万のプロセスを並列実行させることができるらしい. http://www.atmarkit.co.jp/news/200704/27/erlang.html 私は並列言語はVHDLしか使ったことがなく,しかもVHDLはちゃんと 並列実行を行う要素が回路の形で実在するので,Erlangみたいに 1マシンで並列性を実現することに対して
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
A Design Framework for Highly Concurrent Systems Matt Welsh, Steven D. Gribble, Eric A. Brewer, and David Culler Computer Science Division University of California, Berkeley Berkeley, CA 94720 USA {mdw,gribble,brewer,culler}@cs.berkeley.edu Abstract Buil
A Design Framework for Highly Concurrent Systems Matt Welsh, Steven D. Gribble, Eric A. Brewer, and David Culler Computer Science Division University of California, Berkeley Berkeley, CA 94720 USA {mdw,gribble,brewer,culler}@cs.berkeley.edu Abstract Building highly concurrent systems, such as large-scale Internet services, requires managing many information flows at once and maintaining peak throu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
EventMachine: 高速でスケーラブルなEvent-Driven I/Oフレームワーク
はてなブログ | 無料ブログを作成しよう
libev v.s. libevent
http://dekorte.com/projects/opensource/libcoroutine/
The C10K Problem 日本語訳