Date | Commit message (Collapse) |
|
Ruby trunk started warning about more mismatched indentations
starting around r62836.
|
|
Less code in cold paths can improve speed for hot paths.
Single-byte strings for String#split is optimized in mainline Ruby,
so it's not actually a performance loss for sendfile_range in
response.rb
Regexps are at least 400 bytes each, so prefer non-Regexps
if possible, especially for cold sites where performance does
not matter.
|
|
We'll need this for unicorn 5, as they dropped this publically
accessible attribute while retaining the ivar. Eventually we
may not have to check this attribute at all, instead detecting
parent death via worker pipe.
|
|
unicorn 5 dropped support for this, essentially allowing unlimited
persistent connections if we used the parser as-is.
Since most of our concurrency models cannot handle infinite
persistent connections without being vulnerable to DoS,
we must support keepalive_requests like nginx does.
|
|
Telling the user worker_connections=50 when using the Base
concurrency model is misleading.
|
|
Unicorn (> 4.0.1) already handles this for us,
not that it affects many people...
This reverts commit 37c376a9253ed62d134cbb4dbc6eaecc6076c77e.
|
|
We can't wait for longer than 68 years.
|
|
Lowering this will lower worst-case memory usage and mitigate some
denial-of-service attacks. This should be larger than
client_header_buffer_size.
The default value is carried over from Mongrel and Unicorn.
|
|
We may not always use Rainbows! :Base since we don't want
keepalive/immediate log reopening in some cases.
|
|
Only needed for Ruby 1.9
|
|
This allows using IO::Splice.copy_stream from the "io_splice"
RubyGem on recent Linux systems. This also allows users to
disable copy_stream usage entirely and use traditional
response_body.each calls which are compatible with all Rack
servers (to workaround bugs in IO.copy_stream under 1.9.2-p180).
|
|
There's actually no reason we can't have these methods
in Rainbows::Configurator where it's easier to document
nowadays.
|
|
It *can* have as many threads as it does idle connections.
|
|
We won't forget to reset defaults on SIGHUP anymore.
|
|
Too confusing otherwise...
|
|
We're changing our default to 1K buffers to save memory. This
should reduce memory usage of idle clients and lower pressure on
the MRI GC. Rails applications using session cookies (the
default) may want to up this to 2K or more.
|
|
pavinging the way for changing MODEL_WORKER_CONNECTIONS
|
|
Might as well, threads are free and cheap on 64-bit
|
|
In case people try to do C10K, make life easier for them.
|
|
Ugh the old way was gross.
|
|
Run under 1.9.3dev
|
|
Actually use the Rainbows::O constant for use
[ew: rewritten commit message subject]
Acked-by: Eric Wong <normalperson@yhbt.net>
|
|
Ugh, I need to think of a way to clean this up...
|
|
It's too long especially since XEpollThreadPool is planned :>
|
|
Edge-triggered epoll concurrency model with blocking accept() in
a (hopefully) native thread. This is recommended over Epoll for
Ruby 1.9 users as it can workaround accept()-scalability issues
on multicore machines.
|
|
Coolio and EventMachine only use level-triggered epoll,
but being Rainbows!, we live on the EDGE!
|
|
Code organization is hard :<
|
|
Easier just to use an instance variable
|
|
This will allow servers to limit the number of keepalive
requests that can be made over a single connection to
prevent denial-of-service and also to improve fairness
in load-balancing.
|
|
Cool.io is the new name for Rev. We'll continue to support Rev
until Cool.io breaks backwards compatibility. Rev may not be
supported if Cool.io is.
|
|
For consistency, changed settings are reset back to
their default values if they are removed or commented
out from the config file.
|
|
This simplifies and disambiguates most constant resolution
issues as well as lowering our identation level. Hopefully
this makes code easier to understand.
|
|
We get basic internal API changes from Unicorn,
code simplifications coming next.
|
|
Sometimes we have stupid syntax or constant resolution
errors in our code.
|
|
Since we suck at building websites, we just rely on RDoc as a
website builder. And since Rainbows! is an application server
(and not a programming library), our internal API should be of
little interest to end users.
Anybody interested in Rainbows! (or any other project) internals
should be reading the source.
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
duh!
|
|
Since we have conditional deferred execution in the regular
EventMachine concurrency model, we can drop this one.
This concurrency model never fully worked due to lack of
graceful shut downs, and was never promoted nor supported, either.
|
|
Since Rainbows! is supported when exposed directly to the
Internet, administrators may want to limit the amount of data a
user may upload in a single request body to prevent a
denial-of-service via disk space exhaustion.
This amount may be specified in bytes, the default limit being
1024*1024 bytes (1 megabyte). To override this default, a user
may specify `client_max_body_size' in the Rainbows! block
of their server config file:
Rainbows! do
client_max_body_size 10 * 1024 * 1024
end
Clients that exceed the limit will get a "413 Request Entity Too
Large" response if the request body is too large and the
connection will close.
For chunked requests, we have no choice but to interrupt during
the client upload since we have no prior knowledge of the
request body size.
|
|
http_response and http_server are never NOT loaded when
"rainbows" is required.
|
|
There's a good chunk of tests that fail with this, still.
Worse, I haven't been able to figure out what's wrong since
it looks like it would involve looking at C++ code...
|
|
|
|
Eventually we hope to be able to accept arguments like
the way Rack handlers do it:
use :Foo, :bool1, :bool2, :option => value
|
|
And change the default to 2 seconds, most clients can
render the page and load all URLs within 2 seconds.
|
|
This reverts commit e1dcadef6ca242e36e99aab19e3e040bf01070f9.
This is fixed separately in Unicorn 0.95.0 (commit
560216c2fecfc5cf3489f749dc7a0221fd78eb26)
|
|
Permissions for the logs could've been badly set by the master.
So we we'll let the master reopen them and refork children to
get around this problem. We have to be more careful when
reopening logs because we can reopen them in the middle of
client requests (we have to) whereas Unicorn has the luxury
of _knowing_ it has no active clients when it does the reopen.
|
|
It's already global...
|
|
Loading TeeInput or HttpResponse late does not always work well
in multithreaded situations and have been causing random test
failures on heavily loaded multicore boxes.
|
|
This is because our timeout implementations are less precise
than Unicorn. Since we handle multiple clients with the same
process, we sacrifice precision for performance and instead
implement our fchmod heartbeats at a fixed rate, as doing
fchmod() repeated for short-lived connections would hurt
performance and we have to call fchmod even when connected
clients are idle.
|
|
Since const_get works with a string as well as a symbol,
allow that to be used. It's easier and simpler to just
allow strings as use arguments than to error check and
raise exceptions.
So both of the following should now work:
Rainbows! do
use :Revactor
end
Rainbows! do
use "Revactor"
end
Rainbows! will always use the symbol variant internally,
however, so applications can alway expect env['rainbows.model']
to be a symbol.
|