New Inets

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

New Inets

Sean Hinde-2
Hi,

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
inets version)?

Thanks,
Sean



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.




Reply | Threaded
Open this post in threaded view
|

New Inets

Martin Gustafsson
Hi Friends

I believe that Inets was changed to read in one byte at a time to prevent
users from sending malformed http-request that could krasch Inets. One can
for example send a hostname of 10000 bytes.

However Inets are under complete rewriting, to HTTP/1.1 and I will
see if I can solve this problem in a better way at the same time.

Best regards

Martin Gustafsson






Reply | Threaded
Open this post in threaded view
|

New Inets

Nicolas Niclausse-2
In reply to this post by Sean Hinde-2
>>>>> "Sean" == Sean Hinde <Sean.Hinde> ?crivait:

 Sean> In the R8 Prerelease version I noticed the rather unusual design
 Sean> decision to read the HTTP header 1 octet at a time with
 Sean> successive gen_tcp:recv calls.

 Sean> I wonder if any performance testing was done on this mechanism as
 Sean> it doesn't particularly strike me as optimal.. and it might be
 Sean> very slow indeed...

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)



--
Nicolas NICLAUSSE                       IDEALX S.A.S.
T?l:01 44 42 00 00                      http://IDEALX.org/


Reply | Threaded
Open this post in threaded view
|

New Inets

Mickael Remond-2
In reply to this post by Sean Hinde-2
Sean Hinde (Sean.Hinde) wrote:
> Hi,
>
> Inets was the inspiration for our tcp server process structure so I always
> have a look inside when there is a new version.

I think Inets is a good basis for many development and that we should
increase its quality and efficiency when possible.
Are there any plans to make use of binary optimization in Inets ?

By the way, there is a little typo in the inets.app file: A comma is
missing at the end of the mod_htaccess line (Pos 31,25).

Cheers,

--
Micka?l R?mond
http://www.erlang-fr.org/


Reply | Threaded
Open this post in threaded view
|

New Inets

Thierry Mallard-3
In reply to this post by Nicolas Niclausse-2
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 ?

--
Thierry Mallard       http://www.vawis.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20011001/73db94b1/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

New Inets

Nicolas Niclausse-2
>>>>> "tsm" == Thierry Mallard <shaman> ?crivait:

 >> httperf --hog --server schultze --port 8888 --num-conn 1000 --rate
 >> 150 (150 requests sent per sec. to a html file of 4100bytes)

 tsm> I'm wondering how much concurrency we get here... (how many
 tsm> simultaneaous connection there is to the server). Any idea ?

yes, httperf gives the maximum number of concurrent connections:

R8:    Connection rate: 63.1 conn/s (15.9 ms/conn, <=685 concurrent connections)
R7:    Connection rate: 103.6 conn/s (9.7 ms/conn, <=200 concurrent connections)
Apache:Connection rate: 142.9 conn/s (7.0 ms/conn, <=33 concurrent connections)

(MaxClients was set to 950)

--
Nicolas NICLAUSSE                       IDEALX S.A.S.
T?l:01 44 42 00 00                      http://IDEALX.org/


Reply | Threaded
Open this post in threaded view
|

New Inets

Thierry Mallard-3
On Tue, Oct 02, 2001 at 10:11:39AM +0200, Nicolas Niclausse wrote:
> >>>>> "tsm" == Thierry Mallard <shaman> ?crivait:
> [ about concurrency ]

> yes, httperf gives the maximum number of concurrent connections:
>
> R8:    Connection rate: 63.1 conn/s (15.9 ms/conn, <=685 concurrent connections)
> R7:    Connection rate: 103.6 conn/s (9.7 ms/conn, <=200 concurrent connections)
> Apache:Connection rate: 142.9 conn/s (7.0 ms/conn, <=33 concurrent connections)

Hmm.. the problem here is that the concurrency is directly dependent of the
processing speed of the server. Apache process requests quickly, so it never
had more concurrency.

Maybe a complementary bench using "ab" would be usefull for that..

Thanks for the replies, anyway :-)
--
Thierry Mallard       http://www.vawis.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20011002/29af5d63/attachment.bin>