Inets performance

[Miguel Barreiro Paz]

	Hi,

> I made all the tests with ab lauching 5000 connections in a row, using
> 50 simultaneous connections.

> 1. The test client is on the _same_ machine than the Web server:
> Inets: 240 requests per second (classic Apache/Debian index.html)
> Apache: 540 requests per second (classic Apache/Debian index.html)
	
> 2. The test client is on a _different_ machine than the Web server:
> Inets: 205 requests per second (classic Apache/Debian index.html)
> Apache: 182 requests per second (classic Apache/Debian index.html)

	This is pretty anomalous, but could well be caused by a number of
reasons. What is the maximum requests/second you get from apache using ab
-c1 or -c2, and what aggregate throughput are you getting? Apache and
Inets bottlenecks are very different and they show up under extreme
conditions (such as http over the tcp loopback). With a high concurrency
level Apache suffers from heavy context switching, while erlang threads
are obviously far more lightweight. Under high throughput demands, Inets
will suffer badly from its higher cpu overhead compared to Apache (who
quickly gets I/O bound before processor is a bottleneck, unless you abuse
quite a bit of rewriting rules and such). I suppose Apache on Linux
nowadays will serve html files with sendfile(2) directly if it can (ie.,
unless it has to parse shtml or so), thus avoiding a copy, a userspace
buffer, and at least two kernel-userspace switches per write. That is
close to as fast as you can get without hardcore kernelHTTPd solutions :)

> Hum. This is very interesting... From what I understand, Apache seems
> to make a better use of the kernel capability for local connections, but
> Inets performs nearly the same via the network or on the local machine.

	The only special support for local connections is the fast path on
the kernel IP stack, which you will use as soon as you send through the
loopback. You could certainly tune tcp for such conditions, but AFAIK the
tunable tcp timers are global and not settable per-interface on Linux.

> Do you have any idea of why is there such a difference for large file ?

	Sean's suggestion certainly avoids the cost of going through the
file server and should speed up things, has anyone measured the
difference?

	In my very limited experience with inets, I have found a bit
limiting that it can't serve streams, only finite-length data. And as far
as I remember it won't serve anything produced by an erlet until the erlet
has finished its output.

Regards,

Miguel