mORMot

ab wrote: It is because your code is incorrect. The JSON is an object holding an array, not an array itself.   Ok, thanks!

I spend days tracking - and fixing - several issues.The main problem was that the sockets were not closed when epoll() was used!Then I have discovered several difficult race condition bugs, when heavy multi-threading was involved.Also enhanced the ... [More] MaxPending value to 10000 - the previous 2000 did make the server reject connections on heavy benchmark.Now I have no trouble with HTTP/1.1 or HTTP/1.0, with thousands of connections.For instance, here are numbers with forcing HTTP/1.0, and 50 threads running 29980 requests, therefore connections: 1.1. Multi thread process: - Create thread pool: 1 assertion passed 3.03ms - TCP sockets: 119,921 assertions passed 4.18s 1=11682/s 2=16590/s 5=18688/s 10=19351/s 30=14645/s 50=14223/s MaxThreads=50 MaxClients=5000 TotalOps=29980 TotalClients=9800 HTTP1.0 Total failed: 0 / 119,922 - Multi thread process PASSED 4.25sYour feedback is welcome.About the remaining socket errors above 1000 clients with WRK, I guess the problem rely on the WRK tool itself.It first connect every client in a loop, then start working with the clients. This is not well handled by our server. I have no trouble with the ORM multi-thread client code, which uses a more regular pattern. My guess is that WRK behaves not like a regular set of clients, but like a DOS attacker. I consider the socket failure when bombing the server as a security feature, if more regular clients do connect with no problem.I am only concerned about nginx as HTTP/1.0 reverse proxy. Perhaps in this case, the regular useHttpSocket web server should be defined instead of useHttpAsync - this is what is currently documented, by the way. [Less]

I did revert your changes.https://github.com/synopse/mORMot2/pull/73Code added into TRestServerUriContext.ExecuteSoaByMethod slows down execution of regular methods, and I am not sure it is very stable about the actual methods process.It is very ... [More] unsafe to play with the method indexes once the server is initialized, because a lot of code rely on them to be stable enough.I guess there are other means of dynamic registration of services.The easiest (and safest) is to stop and restart the server. [Less]

Test results: - Server stable in case clients are HTTP 1.1, 1.0 and mix of HTTP1.1. and 1.0. - I can't reproduce a delay anymoreBut HTTP1.0 mode still too slow ~1864 RPSThe strange thing is what in HTTP 1.0 mode server consume only small part of CPU ... [More] (each core is about ~10%), while in HTTP 1.1 - 100%I analyse a syscalls  - everything is OKTry to profile via valgrind - and got another strange result - if sample profiler is active all responses are non 200, in verbose mode server start reporting warn mormot.net.async.THttpAsyncConnections(04b36040) Execute: Accept(8888) failed as Too Many Connectionswhat is not true, because ss -s shows 3595 socket in usePS test result above is done before Edit2 added in post aboveEdit2 with latest commit result is the same [Less]

I confirm there is no problem of huge number of concurrent connections using Unix Domain Sockets.If I first runulimit -H -nthen I can run the following tests: 1.1. Multi thread process: - Create thread pool: 1 assertion passed 7.37ms - Unix ... [More] domain sockets: 1,918,959 assertions passed 1m12 1=17764/s 2=16365/s 5=19613/s MaxThreads=5 MaxClients=80000 TotalOps=480000 TotalClients=128000 Total failed: 0 / 1,918,960 - Multi thread process PASSED 1m12So here 80,000 concurrent clients with HTTP/1.1 keep alive stream, with no issue of REST Add/Retrieve process on ORM + SQLite3 database, and perfect scaling.We can see that its scales much better than TCP sockets, from the numbers on my previous post.Such numbers were impossible to reach with mORMot 1 server. [Less]

  True, and so, with the documentation chapter #13.2, the #6.2.4 sentence and the following blogpost, the road should be shorter:https://blog.synopse.info/?post/2013/02 … SQL-access

@tbo  hi Thomas, thank you again. I ended up using THttpClientSocket class directly, instead of the function HttpGet. THttpClientSocket has a constructor that allows specifying a non-default time out.

Please try https://github.com/synopse/mORMot2/commit/98d97175From my tests, epoll API should use much less OS API calls, and also better performance in keep alive (HTTP/1.1) mode. Also when upgraded to WebSockets.Still need to tune the multi ... [More] connection (HTTP/1.0) performance.I am looking forward to your feedback and numbers.Edit: Please check also https://github.com/synopse/mORMot2/commit/013be075It should enhanced HTTP/1.0 performance on small requests. [Less]

Because i live under a rock and don't have a Github account An e-mail with a link could be arranged to someone willing to do it.

So it is about polling for writes.Most of the time, there is no pending output to write. So I guess polling here does not make any sense.I will poll only if needed.The fpc_initialize/finalize are for the local sub/new records.IIRC epoll_wait() can ... [More] still run in a thread while epoll_ctl() is done in another thread.So I guess that on Linux we could use a single fPoll[], then use epoll_wait() timeout for waiting instead of polling.For select and poll (Windows and BSD), this is not possible because those are not thread-safe. [Less]