Inets was the inspiration for our tcp server process structure so I always
have a look inside when there is a new version.
In the R8 Prerelease version I noticed the rather unusual design decision to
read the HTTP header 1 octet at a time with successive gen_tcp:recv calls.
I wonder if any performance testing was done on this mechanism as it doesn't
particularly strike me as optimal.. and it might be very slow indeed...
I also noticed that there is now a driver option to gen_tcp:socket (http)
which returns decoded http headers straight from the socket. Is it intended
that this becomes a fully supported part of OTP (or even used by a future
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
On Mon, Oct 01, 2001 at 04:19:11PM +0200, Nicolas Niclausse wrote:
> [ INETS ]
> Indeed, i've just made a quick benchmark with httperf, and R8 is much
> slower (using the same conf. file)
> httperf --hog --server schultze --port 8888 --num-conn 1000 --rate 150
> (150 requests sent per sec. to a html file of 4100bytes)
> R8-2001.09.24 Request rate: 63.1 req/s (15.9 ms/req)
> R7B3 Request rate: 103.6 req/s (9.7 ms/req)
> Apache 1.3.20 Request rate: 142.9 req/s (7.0 ms/req)
I'm wondering how much concurrency we get here... (how many simultaneaous
connection there is to the server). Any idea ?