[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] Introducing RProxy (and a re-introduction to libevhtp)
- To: libevent-users@xxxxxxxxxxxxx
- Subject: Re: [Libevent-users] Introducing RProxy (and a re-introduction to libevhtp)
- From: Vincent Bernat <bernat@xxxxxxxx>
- Date: Mon, 21 May 2012 18:56:22 +0200
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: libevent-users-outgoing@xxxxxxxx
- Delivered-to: libevent-users@xxxxxxxx
- Delivery-date: Mon, 21 May 2012 12:56:33 -0400
- Dkim-signature: v=1; a=rsa-sha1; c=simple; d=luffy.cx; h=from:to:subject :in-reply-to:references:date:message-id:mime-version :content-type:content-transfer-encoding; s=postfix; bh=2jMJNLMfn 3kMHUjNeSclypetrLg=; b=r7CMUhd7dARxYhO4BNzpsFgTEngUk3sjlWdcRe5cn 8K4Rw2yd2vAP6Yg5hQ+AycGV2oVffvfsOu38WgD9ivWzTHunbQGjWR8SYYJNvD8R aYmfTxJXkUXCmC35GNvkhEM7KpPkJeDPXss+4Ov5lKdoKTFsCSaR0aOSgTiOabOg RQ=
- Domainkey-signature: a=rsa-sha1; c=simple; d=luffy.cx; h=from:to:subject :in-reply-to:references:date:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=postfix; b=P0D anHvSCFhTGuROWlPhbzPFD1XBTbguz89tKEqawEthuZz1wXxgVDD/nNDauPIrXTj Z47LrD1xlU4h+rdySTMauG97438wd/nIa6EotRk842DiOZLrQv/uu/CGr2/u7PQj FqkrGV3qstn73TECxttlO1NV28DGdnUd8pmOTFjY=
- In-reply-to: <20120521162926.GC13774@xxxxxxxxxx> (Mark Ellzey's message of "Mon, 21 May 2012 11:29:26 -0500")
- Organization: One Piece
- References: <20120521162926.GC13774@xxxxxxxxxx>
- Reply-to: libevent-users@xxxxxxxxxxxxx
- Sender: owner-libevent-users@xxxxxxxxxxxxx
- User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (x86_64-pc-linux-gnu)
OoO Lors de la soirÃe naissante du lundi 21 mai 2012, vers 18:29, Mark
Ellzey <mthomas@xxxxxxxxxx> disaitÂ:
> Many of the wonderful open-source proxies that exist today are tailored to the
> average GET <-> RESPONSE traffic types. For each request, they may spawn a new
> thread, create a new connection to the back-end, or both. Many of the projects
> we analyzed could not handle large streams of data efficiently since they would
> block until the full client request has been received (hey, where did my memory
> go?). Resource exhaustion was a common element under high load: memory, file
> descriptors, CPU, etc. These existing projects are designed perfectly for common
> traffic flows, but can quickly capsize under pressure.
Did you try haproxy + stunnel or haproxy + stud? Your project seems
pretty interesting. I plan to benchmark it against other HTTP SSL
termination solutions.
--
Vincent Bernat â http://vincent.bernat.im
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.