DEPLOY FAQ HACKING LICENSE NEWS README SIGNALS Sandbox Static_Files Summary TUNING Test_Suite rainbows_1 vs_Unicorn
Rainbows ActorSpawn AppPool Base Configurator Coolio CoolioThreadPool CoolioThreadSpawn DevFdResponse Epoll EventMachine FiberPool FiberSpawn MaxBody NeverBlock Rev RevFiberSpawn RevThreadPool RevThreadSpawn Revactor Sendfile ServerToken StreamResponseEpoll ThreadPool ThreadSpawn ThreadTimeout WriterThreadPool WriterThreadSpawn XEpoll XEpollThreadPool XEpollThreadSpawn

module Rainbows::XEpollThreadPool

This is an edge-triggered epoll concurrency model with blocking accept() in a (hopefully) native thread. This is comparable to ThreadPool and CoolioThreadPool, but is Linux-only and able to exploit "wake one" accept() behavior of a blocking accept() call when used with native threads.

This supports streaming "rack.input" and allows :pool_size tuning independently of worker_connections

Disadvantages

This is only supported under Linux 2.6 and later kernels.

Compared to CoolioThreadPool

This does not buffer outgoing responses in userspace at all, meaning it can lower response latency to fast clients and also prevent starvation of other clients when reading slow disks for responses (when combined with native threads).

CoolioThreadPool is likely better for trickling large static files or proxying responses to slow clients, but this is likely better for fast clients.

Unlikely CoolioThreadPool, this supports streaming "rack.input" which is useful for reading large uploads from fast clients.

This exposes no special API or extensions on top of Rack.

Compared to ThreadPool

This can maintain idle connections without the memory overhead of an idle Thread. The cost of handling/dispatching active connections is exactly the same for an equivalent number of active connections (but independently tunable).

:pool_size vs worker_connections

Since :pool_size and worker_connections are independently tunable, it is possible to get into situations where active connections need to wait for an idle thread in the thread pool before being processed

In your Rainbows! config block, you may specify a Thread pool size to limit your application concurrency independently of worker_connections.

Rainbows! do
  use :XEpollThreadPool, :pool_size => 50
  worker_connections 100
end

In extremely rare cases, this may be combined with Rainbows::AppPool if you have different concurrency capabilities for different parts of your Rack application.

RubyGem Requirements

Extended with: Rainbows::PoolSize
Pages Classes Methods


mail archives: https://yhbt.net/rainbows-public/
	http://ou63pmih66umazou.onion/rainbows-public/ 
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows 
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.rainbows 
	nntp://news.gmane.io/gmane.comp.lang.ruby.rainbows.general 
public: rainbows-public@yhbt.net
source code: git clone https://yhbt.net/rainbows.git
	torsocks git clone http://ou63pmih66umazou.onion/rainbows.git