Rust で学ぶ epoll - Qiita
動機 Rust の futures はゼロコスト抽象化を謳っており、 Future トレイトは poll メソッドを備えている tokio の polling 戦略を知るには epoll の知識が避けて通れない - https://tokio.rs/docs/getting-started/tasks/ , https://cafbit.com/post/tokio_internals/ , epoll の例は C はたくさんあるけど Rust + nix は皆無だったのでやってみた コード extern crate nix; use nix::sys::epoll::*; use nix::sys::socket::*; use nix::unistd::close; use std::collections::HashMap; use std::os::unix::io::RawFd;
Epoll is fundamentally broken 1/2 — Idea of the day
In previous articles we talked about: The history of the Select(2) syscall Select(2) being fundamentally broken This time we'll focus on Linux's select(2) successor - the epoll(2) I/O multiplexing syscall. Epoll is relatively young. It was created by Davide Libenzi in 2002. For comparison: Windows did IOCP in 1994 and FreeBSD's kqueue was introduced in July 2000. Unfortunately, even though epoll i
A brief history of select(2) — Idea of the day
Recently I've been thinking about the multiplexing in Linux, namely the epoll(7) syscall. I was curious if epoll is better or worse than the iocp or kqueue. I was wondering if there was a benefit in batching epoll_ctl calls. But let's step back for a while, before we start a serious discussion we need to get some context. Most importantly - is file descriptor multiplexing an aberration or a gentle
徒然なるままに｜epollの使い方 ~I/O Multiplexing~
多重I/O(I/O Multiplexing)について勉強する機会があったのでメモ。 具体的な使用方法の前に多重I/Oについての前置き。 多重I/Oとは、複数のプロセスにread(recv)要求を行っている状況において 順番を気にせず、読み込みが完了したプロセスから順次読み込んだデータを使って処理する場合に使う。 いわゆるイベント駆動型動作であり、一つでも読み込みが完了していれば まだ読み込みが終了していないプロセスのread待ちによるブロックがない。 例えば１００プロセスとの通信で、ファイルディスクリプタを１００個所持している状況を考えよう。 １つのプロセスからの入力を待って、入力が来たら、次のプロセスからの入力を待って、・・・として 全てのプロセスからデータを読み込むのは非常に非効率である。 そこで１００個のファイルディスクリプタを監視して、 読み込みイベントがあったファイルディスクリ
nginx Tuning - 12 Days of Performance - REVSYS
nginx is fast, really fast, but you can adjust a few things to make sure it's as fast as possible for your use case. Santa doesn't like it when you spend your hard earned money on extra server resources you don't really need. The easy stuff The easiest thing to set in your configuration is to setup the right number of workers and connections. This tells nginx to only have a single worker process.
がんばらない動的画像変換サーバーのつくりかた - スパイスな人生
tmixエンジニアのid:ksssです。 今年の夏も暑いですね。 僕は最近tmixで作ったドライTシャツを着て、朝のランニングで体力づくりに取り組んでいます。 http://tmix.jp/designs/2052395 このTシャツには、プログラマー界での有名な言葉をもじって「ぐだぐだ言ってないで、走れ！」という意味を込めていて、なまけがちな自分をとっとと走りに行かせようと意識をたかめています。 今回はここに表示されている画像の裏側についてお話したいと思います。 動的画像変換 このTシャツ画像はリクエストを受けたときに指定のサイズの画像を生成して返しています。 動的画像変換を使うと、管理するファイルの削減や、事前処理の単純化、デザインへの柔軟対応などのメリットがあり、tmixでも様々なページで使われています。 動的画像変換には様々な実装がありますが、tmixではあまりがんばらない動的画像
カーネル/VM Advent Calendar 一日目: eventfd, timerfd, signalfd - Emacs ひきこもり生活
ひ、日付? な、なんのことです…!? 最初はfutex()とかカーネルの変更でpostgresqlが遅くなったとかの話をからめようかと思ってたんですがfutex()調べてたらどんどん大きくなってしまったので今回はスキップして(そのうちあるであろう)2回目にまわしとくことに。 ということで、今回はfutex()から似たところ?で、 epoll, kqueue, *fdあたりを簡単にまとめてみようと思います。 select まずはselect()のおさらいを。 こんなふうにサーバにクライアントが5つぶらさがっています。クライアントは常時接続はしていますが、ずっとサーバと通信しているわけではありません。時々サーバにリクエストを投げ、サーバは適宜リクエストに応答します。サーバはsocketを作ってクライアントと通信をしています。 言うまでもないことですが、こんなコードではうまく動きません。 for
橋本商会 » em-websocketで1万クライアント以上さばく方法
em-websocketの接続数の上限が1015ぐらいなんだけど増やせた。forkとかは使わない。 環境はUbuntu12.04。 Macはepoll使えないので無理。 まずこちらを参考にファイルディスクリプタの上限を増やしておく。 ファイルディスクリプタの上限値を増やす – そ、そんなことないんだから！ で、EM::runの前にepollを使うようにしてset_descriptor_table_sizeを設定すればおｋ require 'eventmachine' require 'em-websocket' EM.epoll EM.set_descriptor_table_size 60000 EM::run EM::WebSocket.run :host => "0.0.0.0", :port => 8080 do |ws| ## 略 end end クライアント側はem-webso
epoll, エッジトリガー, EPOLLRDHUP - 誰かの役に立てばいいブログ
このエントリーは社内勉強会用の解説記事です。 普通の人は便利な libev や libuv を使っておきましょう。 epoll はいわゆる C10K 問題に対応するための Linux カーネルが提供する仕組みです。といってもこの問題、32bit 時代のメモリが潤沢ではなかった時代のものなので、いまどき並大抵のプログラムであれば、普通に１コネクション１スレッドで問題ないでしょう。@kazuho 先生がそうおっしゃっていました。 まあ御託はさておいて、epoll のマニュアル読んでもちょいわからないところを補足しておきます。 レベルトリガーとエッジトリガー マニュアルに書いてありますが、簡単に言うとレベルトリガーは指定した状態が満たされるかチェックする方式です。つまりソケットの受信バッファにデータがあれば、epoll_wait を何度呼び出しても必ず read ready が返ってきます。 エ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
