Date | Commit message (Collapse) |
|
proc creation is expensive, so merely use a 48-byte generic ivar
hash slot for @socket instead.
|
|
Rack 1.4 and earlier will soon die out, so avoid having extra code
The only minor overhead is assigning two hash slots and
the extra hash checks when running ancient versions of Rack,
so it is unlikely anybody cares about that overhead with Rack 1.5
and later.
|
|
unicorn 4.9.0 - TempfileReaper support in Rack 1.6
This release supports the Rack::TempfileReaper middleware found
in rack 1.6 for cleaning up disk space used by temporary files.
We also use Rack::TempfileReaper for cleaning up large temporary
files buffered with TeeInput. Users on rack 1.5 and earlier
will see no changes.
There's also a bunch of documentation/build system improvements.
This is likely to be the last Ruby 1.8-compatible release,
unicorn 5.x will require 1.9.3 or later as well as dropping lots
of cruft (the stupid "Status:" header in responses being the
most notable).
21 changes backported from master:
ISSUES: update with mailing list subscription
FAQ: add entry for Rails autoflush_log
dev: remove isolate dependency
unicorn.gemspec: depend on test-unit 3.0
remove RubyForge and Freecode references
remove mongrel.rubyforge.org references
examples: add run_once to before_fork hook example
t/t0002-parser-error.sh: relax test for rack 1.6.0
switch docs + website to olddoc
README: clarify/reduce references to unicorn_rails
gemspec: fixup olddoc migration
GNUmakefile: fix clean gem build + reduce build cruft
doc: update support status for Ruby versions
fix uninstalled testing and reduce require paths
test_socket_helper: do not depend on SO_REUSEPORT
ISSUES: add section for bugs in other projects
explain 11 byte magic number for self-pipe
Links: mark Rainbows! as historical, reference yahns
doc: document UNICORN_FD in manpage
tee_input: support for Rack::TempfileReaper middleware
support TempfileReaper in deployment and development envs
* tag 'v4.9.0': (22 commits)
unicorn 4.9.0 - TempfileReaper support in Rack 1.6
support TempfileReaper in deployment and development envs
tee_input: support for Rack::TempfileReaper middleware
doc: document UNICORN_FD in manpage
Links: mark Rainbows! as historical, reference yahns
explain 11 byte magic number for self-pipe
ISSUES: add section for bugs in other projects
test_socket_helper: do not depend on SO_REUSEPORT
fix uninstalled testing and reduce require paths
doc: update support status for Ruby versions
GNUmakefile: fix clean gem build + reduce build cruft
gemspec: fixup olddoc migration
README: clarify/reduce references to unicorn_rails
switch docs + website to olddoc
t/t0002-parser-error.sh: relax test for rack 1.6.0
examples: add run_once to before_fork hook example
remove mongrel.rubyforge.org references
remove RubyForge and Freecode references
unicorn.gemspec: depend on test-unit 3.0
dev: remove isolate dependency
...
|
|
kgio_wait_readable is superior for single FDs in that it may use the
ppoll syscall on Linux via Ruby, making it immune to the slowdown
high FDs with select() and the array allocations enforced by the
Ruby wrapper interface.
Note: IO#wait in the io/wait stdlib has the same effect, but as of
2.2 still needlessly checks the FIONREAD ioctl. So avoid needing to
force a new require on users which also incur shared object loading
costs. The longer term plan is to rely entirely on Ruby IO
primitives entirely and drop kgio, but that won't happen until we
can depend on Ruby 2.3 for exception-free accept_nonblock
(which will be released December 2015).
|
|
This release supports the Rack::TempfileReaper middleware found
in rack 1.6 for cleaning up disk space used by temporary files.
We also use Rack::TempfileReaper for cleaning up large temporary
files buffered with TeeInput. Users on rack 1.5 and earlier
will see no changes.
There's also a bunch of documentation/build system improvements.
This is likely to be the last Ruby 1.8-compatible release, unicorn 5.x
will require 1.9.3 or later as well as dropping lots of cruft (the
stupid "Status:" header in responses being the most notable).
21 changes backported from master:
ISSUES: update with mailing list subscription
FAQ: add entry for Rails autoflush_log
dev: remove isolate dependency
unicorn.gemspec: depend on test-unit 3.0
remove RubyForge and Freecode references
remove mongrel.rubyforge.org references
examples: add run_once to before_fork hook example
t/t0002-parser-error.sh: relax test for rack 1.6.0
switch docs + website to olddoc
README: clarify/reduce references to unicorn_rails
gemspec: fixup olddoc migration
GNUmakefile: fix clean gem build + reduce build cruft
doc: update support status for Ruby versions
fix uninstalled testing and reduce require paths
test_socket_helper: do not depend on SO_REUSEPORT
ISSUES: add section for bugs in other projects
explain 11 byte magic number for self-pipe
Links: mark Rainbows! as historical, reference yahns
doc: document UNICORN_FD in manpage
tee_input: support for Rack::TempfileReaper middleware
support TempfileReaper in deployment and development envs
|
|
rack 1.6 added a TempfileReaper middleware to cleanup temporary
files. Enable it by default for users running rack 1.6 or later
to avoid leaving temporary files around.
|
|
Rack::TempfileReaper was added in rack 1.6 to cleanup temporary
files. Make Unicorn::TmpIO ducktype-compatible so
Rack::TempfileReaper may be used to free up space used by temporary
buffer files.
Ref: <CY1PR0301MB078011EB5A22B733EB222A45A4EE0@CY1PR0301MB0780.namprd03.prod.outlook.com>
Reported-by: Mike Mulvaney <MMulvaney@bna.com>
|
|
rack 1.6 added a TempfileReaper middleware to cleanup temporary
files. Enable it by default for users running rack 1.6 or later
to avoid leaving temporary files around.
|
|
Rack::TempfileReaper was added in rack 1.6 to cleanup temporary
files. Make Unicorn::TmpIO ducktype-compatible so
Rack::TempfileReaper may be used to free up space used by temporary
buffer files.
Ref: <CY1PR0301MB078011EB5A22B733EB222A45A4EE0@CY1PR0301MB0780.namprd03.prod.outlook.com>
Reported-by: Mike Mulvaney <MMulvaney@bna.com>
|
|
Due to the prevalence of socket activation in modern init systems,
we shall document UNICORN_FD (previously an implementation detail)
in the manpage.
|
|
Pushing the boundaries of bad marketing :P
|
|
Oops, this should've been explained long ago but apparently not.
In response to a comment on
http://www.sitepoint.com/the-self-pipe-trick-explained/
> Does anybody know why both unicorn and foreman read 11 bytes from
> self-pipe?
Unfortunately I couldn't find a way to comment on the site on a
JavaScript-free browser nor does it seem possible without
registering.
Again, anybody can send plain-text mail to:
unicorn-public@bogomips.org
No registration, no real name policy, no terms-of-service, just
plain-text. Feel free to use Tor, mixmaster or any anonymity
service, too.
|
|
This is not anything new, just documenting what has been going
on since the beginning.
There's been a small number of generic networking (or mm) bugs in
the kernel which affect unicorn, but are usually found and fixed
with more popular, non-Ruby servers, first.
Aside from generic performance problems, I don't think there's ever
been a glibc bug which affected unicorn.
|
|
Older Rubies (2.0) may not define SO_REUSEPORT even if the
kernel and libc support it
|
|
This fixes a bug introduced in
commit fe83ead4eae6f011fa15f506cd80cb4256813a92
(GNUmakefile: fix clean gem build + reduce build cruft)
which broke clean Ruby installations without an existing
unicorn gem installed :x
[fixed test/unit/test_http_parser_xftrust.rb for backport]
|
|
unicorn 5 will not support Ruby 1.8 anymore.
Drop mentions of Rubinius, too, it's too difficult to support due to
the proprietary and registration-required nature of its bug tracker.
The smaller memory footprint and CoW-friendly memory allocator in
mainline Ruby is a better fit for unicorn, anyways.
Since Ruby 1.9+ bundles RubyGems and gem startup is faster nowadays,
we'll just depend on that instead of not loading RubyGems.
Drop the local.mk.sample file, too, since it's way out-of-date
and probably isn't useful (I have not used it in a while).
[reinstate 1.9 version check for listener_fds in backport]
|
|
Ensure we have a NEWS file for building the gem beforehand.
We don't need to polute lib/ with object files, either.
|
|
rdoc_options is no longer necesary with olddoc as olddoc can
infer document titles and only generates cgit-compatible URLs
to source code.
|
|
unicorn_rails is an ancient compatibility wrapper for ancient
versions of Rails which did not use Rack. Those applications have
likely moved on, so stop promoting unicorn_rails.
|
|
wrongdoc was difficult to maintain because of the tidy-ffi
dependency and the HTML5 changes in Darkfish could not be
handled well by Tidy.
olddoc is superior as it generates leaner HTML which loads faster,
requires less scrolling and less processing power to render.
Aesthetic comparisons are subjective of course but completely
unimportant compared to speed and accessibility.
The presence of images and CSS on the old (Darkfish-based) site
probably set unreasonable expectations as to my ability and
willingness to view such things. No more, the new website is
entirely simple HTML which renders well with even the wimpiest
browser.
|
|
This overly zealous test was broken by:
rack commit be28c6a2ac152fe4adfbef71f3db9f4200df89e8
("update HTTP status codes to IETF RFC 7231")
|
|
There may be code in a before_fork hook which should run only once,
document an example using a guard variable since it may not be
immediately obvious to all users.
Inspired-by: BrĂ¡ulio Bhavamitra <braulio@eita.org.br>
http://bogomips.org/unicorn-public/m/20141004015707.GA1951@dcvr.yhbt.net.html
|
|
mongrel.rubyforge.org has been dead longer than rubyforge.org!
|
|
Both sites are gone.
|
|
test-unit 3 and minitest 5 will have equal support status as a
bundled gems when Ruby 2.2.0 is released in December 2014. These
bundled gems will appear in the user-oriented tarball installations,
but do not get installed by "make install" when installing Ruby
from SVN or git.
test-unit appears to be actively maintained and good at keeping
backwards compatibility even on a major version change, so this
means no code changes on our end. I am not convinced switching to
minitest is worth the effort.
Cc: Ken Dreyer <ktdreyer@ktdreyer.com>
|
|
It seems unnecessary with current versions of RubyGems
supporting development dependencies.
|
|
Thanks to Cedric Maion for bringing this up on the mailing list:
http://bogomips.org/unicorn-public/m/20140703144048.GA6674@cedric-maion.com
|
|
mlmmj seems quite usable and maintainable, so we'll run it.
|
|
Literal regexps cost over 450 bytes of memory per-site and
unnecessary use of them costs memory in places where raw execution
speed does not matter. Nowadays, we can rely on String#end_with?
(introduced in 1.8.7) for improved readability, too.
|
|
Ruby 2.2 has Etc.nprocessors, and using that (directly or as a
factor) for setting worker_processes is often (but not always)
appropriate.
|
|
Due to the prevalence of socket activation in modern init systems,
we shall document UNICORN_FD (previously an implementation detail)
in the manpage.
|
|
We had HTTPS support but dropped it(*) and some wacky servers out
there do work better with TCP_DEFER_ACCEPT disabled.
(*) No, we will not support HTTP/2, that is for nginx
|
|
It was never used anywhere AFAIK and wastes precious bytes.
|
|
We use the `clear' method everywhere nowadays.
|
|
Empty classes do not need a heavy class definition scope.
|
|
Pushing the boundaries of bad marketing :P
|
|
Literal String#freeze avoids allocations since Ruby 2.1 via the
opt_str_freeze instruction, so we can start relying on it in
some places as Ruby 2.1 adoption increases. The 100-continue
handling is a good place to start since it is an uncommonly-used
code path which benefits from size reduction and the negative
performance impact is restricted to a handful of users.
HTTP_RESPONSE_START can safely live in http_request.rb as its
usage does not cross namespace boundaries
The goal is to eventually eliminate Unicorn::Const entirely.
|
|
Rainbows! (in maintenance mode) will need to define it's own
constants in the future. We'll trim down our constant usage in
subsequent commits as we take advantage of Ruby VM improvements.
|
|
Oops, this should've been explained long ago but apparently not.
In response to a comment on
http://www.sitepoint.com/the-self-pipe-trick-explained/
> Does anybody know why both unicorn and foreman read 11 bytes from
> self-pipe?
Unfortunately I couldn't find a way to comment on the site on a
JavaScript-free browser nor does it seem possible without
registering.
Again, anybody can send plain-text mail to:
unicorn-public@bogomips.org
No registration, no real name policy, no terms-of-service, just
plain-text. Feel free to use Tor, mixmaster or any anonymity
service, too.
|
|
In 1.9+ at least, instance variables use less space than constants
in class tables and bytecode, leading to ~700 byte reduction in
bytecode overhead on 64-bit and a reduction in constant table/entries
of the Unicorn::HttpServer class.
|
|
This is not anything new, just documenting what has been going
on since the beginning.
There's been a small number of generic networking (or mm) bugs in
the kernel which affect unicorn, but are usually found and fixed
with more popular, non-Ruby servers, first.
Aside from generic performance problems, I don't think there's ever
been a glibc bug which affected unicorn.
|
|
The former is shorter Ruby code and also generates smaller
bytecode.
|
|
Older Rubies (2.0) may not define SO_REUSEPORT even if the
kernel and libc support it
|
|
This fixes a bug introduced in
commit fe83ead4eae6f011fa15f506cd80cb4256813a92
(GNUmakefile: fix clean gem build + reduce build cruft)
which broke clean Ruby installations without an existing
unicorn gem installed :x
|
|
unicorn 5 will not support Ruby 1.8 anymore.
Drop mentions of Rubinius, too, it's too difficult to support due to
the proprietary and registration-required nature of its bug tracker.
The smaller memory footprint and CoW-friendly memory allocator in
mainline Ruby is a better fit for unicorn, anyways.
Since Ruby 1.9+ bundles RubyGems and gem startup is faster nowadays,
we'll just depend on that instead of not loading RubyGems.
Drop the local.mk.sample file, too, since it's way out-of-date
and probably isn't useful (I have not used it in a while).
|
|
require_relative appeared in Ruby 1.9.2 to speed up load times by
avoiding needless open() syscalls. This has no effect if you're using
RUBYLIB or the '-I' option when running ruby(1), but avoids searching
paths in other gems.
This does not affect unicorn greatly as unicorn does not activate many
gems, but still leads to reducing ~45 syscalls during startup.
|
|
IO#close_on_exec* methods are available since Ruby 1.9.1. It
allows us to use less bytecode as it requires fewer operands and
avoids constant lookups.
|
|
We're requiring Ruby 1.9.3+, so we can safely depend
on IO#autoclose= being available in 1.9+ and shave off
some bloat.
|
|
In Ruby 1.9.2+, socket options may be specified using symbols
instead of constants to avoid the need to import Socket::Constants
into the namespace. This also has a nice side-effect of reducing
the size of the bytecode by trading 3 instructions (getinlinecache,
getconstant, setinlinecache) for one "putobject" instruction.
Nowadays, we may also avoid defining OS-specific constants ourselves
since 1.9+ versions of Ruby already provide them to further reduce
bytecode size.
getsockopt also returns Socket::Option objects in 1.9.2+,
allowing us to avoid the larger "unpack('i')" method dispatch
for an operand-free "int" method call.
Finally, favor Object#nil? calls rather than "== nil" comparisons
to reduce bytecode size even more.
Since this code is only called at startup time, it does not benefit
from inline caching of constant lookups in current mainline Ruby.
Combined, these changes reduce YARV bytecode size by around 2K on a
64-bit system.
|
|
Ensure we have a NEWS file for building the gem beforehand.
We don't need to polute lib/ with object files, either.
|