Re: scalable server

Hi Anne,

On 10/02/2013 03:54 AM, Anne Ogborn wrote:
> final version - on my modest server this is currently serving about 1100 requests/sec

What is this modest server (OS and hardware)?

> % load the multi-threaded http server
> :- use_module(library(http/thread_httpd)).
> % and the standard handler dispatcher
> :- use_module(library(http/http_dispatch)).
>
> :- use_module(library(http/html_write)).
> :- use_module(library(thread_pool)).
> :- use_module(server_stats).
> :- use_module(library(http/http_session)).
>
> :- thread_pool_create(media,   20, []).
>
> 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)?

> 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).

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.

> :- 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.

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

>
> :- http_handler(/, holder, [prefix]).
>
> give_em_the_grape(Request) :-
>       http_reply_file('tnsf.jpg', [cache(true)], Request).
>
> holder(_Request) :-
> reply_html_page(title('Transsexual Rights'),
>    div(p('Please support transsexual women\'s basic human right to live our lives.'))
>   ).
>
>
> :- http_handler('/admin', admin_pg , [spawn(media), priority(20)]).
>
> admin_pg(_Request) :-
> reply_html_page(title('admin'),
> [\http_session_table,
> \http_server_statistics,
> \http_server_pool_table]).
>
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>