Re: scalable server

What is this modest server (OS and hardware)?

It's the $45/month plan at linode.com

anniepoo@localhost:~$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    8
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 45
Stepping:              7
CPU MHz:               2600.058
BogoMIPS:              5200.11
Hypervisor vendor:     Xen
Virtualization type:   para
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              20480K
NUMA node0 CPU(s):     0-7
anniepoo@localhost:~$

2 gig memory
> start :-
> http_set_session_options([enabled(false)]),

Not sure why you'd need to explicitly disable sessions.  I don't
get sessions.  Something you put in .plrc (pl.ini)?

I included your server_stats.pl page - I think it loads the sessions.

> http_server(http_dispatch, [port(80), workers(200), timeout(1),
>    keep_alive_timeout(1)]).

Setting keep_alive_timeout will reduce the number of open sockets.
On the other hand, the max number of connections should be 200+20:
the number of workers + the thread pool size.  Normally you use
Windows AFAIK.  I don't know the limit there.  Default Linux
installations have a limit of 1000 (can be enlarged).

This is on Ubuntu 13.04

Ideally, the system should keep track of the number of open files and
kill keep-alive sessions if the limit gets in sight. Alternatively, it
might be possible to learn from past behaviour to close connections more
aggresively.  For example by rembering the last page and how often that
results in a new request on the connection and how often that results
in a connection timeout.

Lacking these, the thread counts must be configured to limit the number
of connections below the OS limit and keep_alive_timeout can be reduced
to get rid of old connections quicker.

A timeout(1) is unlikely to do anything.  It limits the (wall) time
spent in processing a request.  Considering these trivial requests,
it is highly unlikely that this limit is reached.

Well, the server's pretty heavily loaded at the moment. Changing this number and keep_alive_timeout made
it quit griping about too many open files

> :- http_handler('/tnsf.png', give_em_the_grape, [spawn(media), priority(10)]).

Note that priority(10) only does something if there is a conflicting
handler also serving /tnsf.png.  It has nothing to do with scheduling
or similar things.

Yes - understood. the priority was because there's a handler for / with prefix

Interesting. The most loaded server I have is www.swi-prolog.org, which
I've seen handling up to about 200 concurrent connections. That was a
problem in old versions, but works fine now. The server is running on an
8 core Debian Linux machine (together with a lot of other applications).

    Cheers --- Jan