about summary refs log tree commit homepage
path: root/lib/rainbows/stream_response_epoll.rb
DateCommit message (Collapse)
2015-11-21tiny bytecode reductions for cold paths
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.
2015-11-21stream_response_epoll: remove hijack_prepare call
unicorn 5.0.0 assumes Rack hijack is always available if the application tries to use it, so the wrapper method is removed.
2015-11-18reduce constant lookup dependencies
Unicorn 5 removes some constants we were using, and constant lookups + inline caching are waste of time anyways on newer Rubies with the opt_str_freeze bytecode instruction. This may reduce performance for folks on older Rubies (probably not noticeable); but improves performance for folks on newer Rubies.
2015-11-18reflect changes in Rack::Utils::HTTP_STATUS_CODES
Applications may want to alter the message associated with HTTP status codes in Rack::Utils::HTTP_STATUS_CODES. Avoid memoizing status lines ahead-of-time Note: this introduces a minor performance regression, but ought to be unnoticeable unless you're running "Hello world"-type apps.
2015-11-18kill the moronic Status: header
Whatever compatibility reasons which existed in 2009 likely do not exist now. Other servers (e.g. thin, puma) seem to work alright without it, so there's no reason to waste precious bytes.
2013-02-11hijacking support for Rack 1.5.x users
This requires Rack 1.5.x and unicorn 4.6.0 for hijacking support. Older versions of Rack continue to work fine, but we must use unicorn 4.6.0 features to support this.
2012-05-09stream_response_epoll: fix for unicorn 4.3.x
unicorn 4.3.x now calls shutdown() explicitly on the socket, so we can't just rely on a dup()-ed FD to keep a socket around.
2011-06-10stream_response_epoll: update documentation
Yes, this concurrency model is our strangest yet.
2011-06-09stream_response_epoll: our most "special" concurrency option yet
This doesn't use Rainbows::Base so we have no keepalive support at all. This could eventually be an option for streaming applications.