Date | Commit message (Collapse) |
|
ev_core is always loaded after forking, so eliminate the
need for extra setup steps for each concurrency model that
uses it
|
|
It turns out to be less-used than previous anticipated,
so there's no point in having yet another module.
|
|
It's the only place we ever use it
|
|
We handle that locally in rainbows/response now
|
|
Constant strings mean the runtime won't have to allocate new
objects all the time since GC is currently the biggest
performance problem of Ruby 1.9.x in my experience.
|
|
chunked Transfer-Encoding is only valid for HTTP/1.1
|
|
We guarantee the Rack env will exist for the duration of
the request/response cycle, so we can just tweak
"rainbows.autochunk".
|
|
Coolio and EventMachine only use level-triggered epoll,
but being Rainbows!, we live on the EDGE!
|
|
Single-threaded concurrency models can reuse a single
buffer to avoid thrashing memory and causing unnecessary
GC activity.
|
|
There is one incompatible change: We no longer assume application
authors are crazy and use strangely-cased headers for "Content-Length",
"Transfer-Encoding", and "Range". This allows us to avoid the
case-insensitivity of Rack::Utils::HeaderHash for a speed boost on the
few apps that already serve thousands of requests/second per-worker.
:Coolio got "async.callback" support like :EventMachine, but it
currently lacks EM::Deferrables which would allow us to call
"succeed"/"fail" callbacks. This means only one-shot response writes
are supported.
There are numerous internal code cleanups and several bugfixes for
handling partial static file responses.
|
|
We cannot trigger on_read events and invoke the HTTP parser and
modify @env while we're waiting for an application to run
async.callback. We also need to clear (and *maybe* re-set)
@deferred if we're writing from async.callback
|
|
Both use @deferred to refer to the state where there's a
deferred response body in the queue.
|
|
Nobody uses it anymore
|
|
The lack of an equivlent to EM::Deferrable prevents us from
doing streaming/trickling responses, but a one-shot body
should work fine for Coolio and generating dynamic responses.
|
|
It's more natural and easier to maintain this way
since Coolio::Client is always lazy loaded.
|
|
* lazy load uncommon classes: StreamFile, Response{Chunk,}Pipe
* remove needless rainbows/coolio/sendfile module since we're
lazily loaded now along with the rest of rainbows/coolio/client
and only in the worker.
|
|
We don't want that loaded in the parent process since
we want config reloadability.
|
|
No point in having too many modules to search around
(for both hackers and the runtime).
|
|
Since we support keepalive now, setting @state can be
harmful and the comment is out-of-date.
|
|
We want to put all constants in one place.
|
|
Rack::Utils::HeaderHash is still expensive, so avoid
forcing it on users since we can assume app/library
authors use normally-cased HTTP headers.
|
|
Hash#[] is slightly slower on the miss case due to calling
Hash#default (but faster for the hit case, probably because it
is inlined in 1.9).
|
|
Rack::Lint already stops apps from using it. If a developer
insists on it, then users who inspect their HTTP headers can
point and laugh at them for not using Rack::Lint!
|
|
We already set a Status: header by default for compatibility
with some existing, broken libraries out there.
|
|
Reading headers is common and we don't want to create new String
objects (even if they're tiny or copy-on-write) for the GC to
munch on.
|
|
async.callback will be useful with Coolio (and more!) soon, so
ensure it works as well as the rest of Rainbows!
|
|
This will allow Coolio to use it, too.
|
|
We noticed a few more things that could be cleaned
up after the last commit.
|
|
Code organization is hard :<
|
|
|
|
No need to split it out when there's only a single
class using it.
|
|
Easier just to use an instance variable
|
|
Nagle's algorithm is harmful with the write-write-read sequence
during keepalive, so we disable it performance for users using
keepalive. We always write headers with a separate write
because Rack response bodies may not always be ready for writing
when headers are.
This requires Unicorn 3.3.0
|
|
Yes, I'm still learning Ruby.
|
|
Believe it or not, Time#httpdate showed up at the top
of my profiler output for the past couple of years now.
I guess that's what happens when all HTTP applications
I write are less complex than Rack::Lobster :P
|
|
HeaderHash is quite expensive, and Rack::File currently
uses a regular Ruby Hash with properly-cased headers the
same way they're presented in rfc2616.
|
|
416 responses without a body should respond with a zero
Content-Length and a Content-Range that allows clients
to specify a proper range in the future.
rfc2616, section 14.16 says:
> A server sending a response with status code 416 (Requested
> range not satisfiable) SHOULD include a Content-Range field
> with a byte-range- resp-spec of "*". The instance-length
> specifies the current length of the selected resource.
|
|
Oops
|
|
It's more likely to be in the method cache since Rack::URLMap
uses it and also is more consistent when looking at profiling
output against various concurrency models.
|
|
Rack::Utils::HeaderHash is still very expensive in Rack 1.2,
especially for simple things that we want to run as fast as
possible with minimal interference. HeaderHash is unnecessary
for most requests that do not send Content-Range in responses.
|
|
For consistency with the EventMachine code
|
|
No need to pass unnecessary variables to response_pipe,
just let the client handle it all.
|
|
Unique method names makes it easier to follow code and determine
where our methods come from.
|
|
This lets us simplify repetitive checks worry less about
properly maintaining/closing client connections for each
concurrency model we support.
|
|
Creating unnecessary string objects for every response
is not a good idea.
|
|
Although curl did not complain, 206 is the correct error
code for partial HTTP responses.
|
|
After beefing up and enabling byte range tests for "sendfile"
(and no just IO.copy_stream), we noticed threaded-Coolio
variants did not handle invalid byte ranges correctly.
|
|
Cool.io (new version of Rev) support is explicitly added
(it always worked before). ":Coolio" may be used in place
of ":Rev" anywhere in your Rainbows! config file.
There is a new "keepalive_requests" config directive to limit
the number of requests a single connection may make (default:
100, same as nginx). This may be useful for better
load-balancing characteristics.
The old "Rev" prefixes remain supported as long as Cool.io
remains compatible with Rev (likely forever).
Bug fixes:
* Rainbows::ThreadTimeout middleware with multiple clients
* large, pipelined upload errors with Revactor+Coolio(Rev)
* high CPU usage for maintaining idle keepalive on *Fiber*
* needless ThreadPool wakeups
* request env prematurely cleared keepalive requests,
breaking some middlewares such as Clogger.
* "close" not called on body if wrapper and sendfile used together
Various code cleanups, and our RDoc website is JavaScript-free.
See the ChangeLog or git for all changes.
|
|
We use Cool.io internally everywhere now, but preserve
Rev-based models for anybody using them.
|
|
Some middlewares require the Rack env to be preserved all
the way through to close, so we'll ensure all request models
preserve it.
We also need to better response body wrappers/proxies always get
fired properly when returning. IO.copy_stream and "sendfile"
gem users could hit cases where wrappers did not fire properly.
|