The goal is to allow yahns to become an alternative to nginx for
users running pre-forking HTTP application servers. Some users
are uncomfortable with the commercialized, "open core" nature of
nginx nowadays and would rather use a non-commercial server.
Technically all the pieces are already in place with the buffering
defaults provided by yahns. But the main concern is the 1:1
(yahns)thread:upstream-connection relationship being a waste of system
resources compared to the 1:M relationship which is ideal. So the goal
is to eliminate that for large setups and many upstream processes.
Under most conditions, nginx will always offer better performance
and lower memory usage than yahns. However, yahns currently has
some minor advantages:
1) yahns does _lazy_ output buffering, allowing lower latency to the
first part of a large response.
2) the one-shot, one-event-per-thread-based model provides better
worst-case behavior when serving large files off slow disks
by reducing head-of-line blocking due to slow disk reads.
Furthermore, relying on Ruby in yahns may allow users to migrate
thread-safe endpoints of an Rack app directly into yahns, while
relying on Yahns::ProxyPass to forward non-thread-safe endpoints
to a single-threaded server.
(*) Sure, many folks are also uncomfortable with me being a
Free Software extremist, too, but that's *their* problem :P
