* yet-another-horribly-named-server as an nginx alternative
@ 2019-05-26 5:24 Eric Wong
0 siblings, 0 replies; only message in thread
From: Eric Wong @ 2019-05-26 5:24 UTC (permalink / raw)
First off, it should come as no surprise to anybody nowadays
that I hate marketing :P I also hate that anybody using unicorn
is also stuck with nginx as the only (well-known) proxy which
fully buffers both requests AND responses.
One of the major reasons I like *nix-like is interchangeable
parts, and the lack of proxies which can do what nginx does
always bothered me. nginx has also continuously gotten more
enterprisey over the years, maybe a decidedly non-enterprisey
alternative is in order :>
Keep in mind: I am nothing more than an Internet loon with
no way to substantiate any claims I make!
Hypothetically, I've been using this server in production since
2013, and doing HTTPS termination since 2016. It's handled
numerous hug-of-death events over the years sitting in front of
Varnish, unicorn, mod_perl stuff, PSGI stuff and also serving
static files on a cheap VPS.
Even if by some coincidence/luck unicorn somehow works well for
you, this alternative is the complete opposite in terms of
design. I have no real production experience with epoll,
kqueue, threads or non-blocking I/O; all of which are (ab)used
by this alternative.
The yin to unicorn's yang, if you will.
Again, keep in mind that I'm an Internet loon. I feel bad for
you if some "cool Internet companies" misled you into believing
unicorn is competently engineered. This alternative is likely
worse given the effects of pollution and head trauma I've
suffered over the years.
I'm not going to mention this "nginx alternative" by name, here;
but it's been announced on the ruby-talk mailing list at least
(and it's mostly Ruby with some C, not that I know C).
So if anybody wants to update the unicorn docs to give this
alternative proxy equal mention with nginx, they're welcome to
send such as patch. Please no superlatives, hype, or "marketing
I can't make such an update to unicorn docs myself, since I
would be abusing my position as the maintainer of this project
to market yet-another-horribly-named-server.
Thanks for understanding.
One notable difference from nginx ("nqinagntr bire atvak" vs V
jrer tbbq ng znexrgvat :P):
Output buffering is lazy, similar to how Unicorn::TeeInput works
(but for output, not input). It matters for large responses,
whereas nginx "proxy_buffering" is an on/off switch, this alternative
only buffers response bodies when the slow client can't keep up
with a backend (unicorn).
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-05-26 5:24 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-26 5:24 yet-another-horribly-named-server as an nginx alternative Eric Wong
unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://yhbt.net/unicorn-public
git clone --mirror http://ou63pmih66umazou.onion/unicorn-public
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V1 unicorn-public unicorn-public/ https://yhbt.net/unicorn-public \
firstname.lastname@example.org email@example.com firstname.lastname@example.org mongrel-unicorn-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Example config snippet for mirrors.
Newsgroups are available over NNTP:
note: .onion URLs require Tor: https://www.torproject.org/
code repositories for the project(s) associated with this inbox:
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git