You are not logged in.
Pages: 1
Hello Arnaud,
a setting of ServerKeepAliveTimeOut:= 0 for TRestHttpServer (async) was the reason for 10x slower req times.
I used this option in past (never change a running system) and I reactivated it yesterday without any knowledge about it.
In context of the super fast progress/changing of mORMot may a ask if this option still usefull/relevant yet?
Offline
ServerKeepAliveTimeOut = 0 is documented to disable keep alive.
So may be slower.
BUT it is the case only for THttpServer, not THttpAsyncSerer - which is a bug.
Are you sure you are using THttpAsyncServer?
Offline
Sure is a great word and what does it mean to you, when I am?
Better I show you what the log file says:
20250211 15375400 ! + uHTTPServer.TSOneHttpServer(020f4f28).Create useHttpAsync (secNone) on port 8281
20250211 15375400 ! + mormot.net.async.THttpAsyncConnections(03205f68).Create(THttpAsyncServerConnection,root,32)
20250211 15375401 " info SetThreadName 7f69b8b6c640 140092047279680=R0:root
20250211 15375401 " trace uRestServerDB.TSOneRestServerDB(01dfe208) BeginCurrentThread(TAsyncConnectionsThread) root=root ThreadID=7f69b8b6c640 'R0:root' ThreadCount=1
Offline
Pretty weird.
I have fixed the ServerKeepAliveTimeOut value propagation for the async server:
https://github.com/synopse/mORMot2/commit/1e7d79555
and https://github.com/synopse/mORMot2/commit/e6a34762f
And also ensured ServerKeepAliveTimeOut = 0 disable keep-alive on the async server:
https://github.com/synopse/mORMot2/commit/6d95addbc
Note that ServerKeepAliveTimeOut = 0 seems to actually disable keep-alive, but there is some read errors with the wrk tool (none with curl) during my tests.
- maybe a socket closed too soon?
But anyway, I can't reproduce the "slow down" you observed.
Offline
Interesting.
I hadn't issues with wrk and disabled keep-alive, but
under wrk nothing noticed about performance, but
much slower response times in production.
In production enviroment I use ngingx as a reverse proxy. Perhaps this is the difference.
But wrk and errors sound more like a race condition. Perhaps you could test with heaptrc and gdb for a longer time?
Offline
I'm not using websockets, just plain Http.
But why I shouldn't use async server for that? I use HTTP_DEFAULT_MODE for TRestHttpServer and under linux this leads to useHttpAsync.
And I'm aware (now) of disabled keep alive is not for async server.
What do you mean with plain THttpServer? useHttpSocket?
Offline
The nginx reverse proxy doesn't maintain connections with the reversed server, it makes a HTTP/1.0 transient connection for each request, but still maintain a connection to the final client.
So useHttpSocket is just fine behind a nginx reverse proxy.
Offline
Thanks for explain, make sense.
So when using plain THttpServer, what's your proposal to set ServerKeepAliveTimeOut:= 0 (disabled keep alive)?
I'm creating just a TRestHttpServer which could creates different kinds of HttpServers (Socket, Api, Async) and ServerKeepAliveTimeOut property isn't public over TRestHttpServer.HttpServer.
--> THttpServer(aTRestHttpServerInstance).ServerKeepAliveTimeOut:= 0; <-- looks like a hack
Last edited by danielkuettner (2025-02-12 18:11:34)
Offline
Yes, plain THttpServer and ServerKeepAliveTimeOut:= 0 should work well behind a nginx reverse proxy.
I guess the safe way to change the default value is
(aRestHttpServer.HttpServer as THttpServerSocketGeneric).ServerKeepAliveTimeOut := 0;
Which will work with both THttpServer and THttpAsyncServer classes by the way.
(hint: never force object types, use the "as" keyword or "is" before forcing the type)
Offline
Pages: 1