mORMot Open Source

Perhaps a good way is to put the third-party samples in your own repository and link to it in ex/README.md (many well-known projects do this, calling it a curated list, etc.). In this case, the owner of the third-party repository can change their samples at their own discretion, and the only PR for the mORMot repository is changes to ex/README.md

So problem is not in HTTP pipelining.
Hope Daniel gives us a way to reproduce this issue

We have the result for TFB with FPC_X64MM - it still fails for /plaintext, it also fails for /cachedqueries (ORM) and very low results for /fortunes. We'll have the log in a few days - maybe we'll see something interesting there...

FYI: exception is

free(): invalid size

The round including PR 9121 started on 2024-07-01, so hopefully ~2024-07-04 we will complete plaintext without GPF

WOW!!! That's just great!
I will immediately do PR for TFB.

Updated PR 9072:
- migrate to Ubuntu24.04;
- mORMot@2.2.7579;
- return to glibc MM;
- plaintext is run after cached-queries
  - define FPC_LIBCMM_NOMSIZE to disable the malloc_usable_size() call on Linux
- use O3 compiler optimization level

Hope that FPC_LIBCMM_NOMSIZE or -O3 will help

Made a PR 9072:
  -  migrate to Ubuntu24.04;
  -  mORMot@2.2.7565;
  -  return to glibc MM;
  -  plaintext is run after cached-queries

I suspect Conditional jump or move depends on uninitialised value(s) in mormot.net.http.pas:3693 can be our problem - this is ProcessParseLine call

Result with mimalloc is ready. Server crushes again on /plaintext (but runs a little longer)
Previous round craches with double free or corruption (out), for round with mimalloc log is not ready yet - may be it output gives us some ideas
But in general, mimalloc is slower than glibc, so I remove it and move /plaintext to be a last test (currently it is behind /cached-queries)

I expect that LD_PRELOAD works, because in  case of invalid path to library I have been getting a warning.
I still can't run a ./raw on my machine, only in docker. Hope repair it and check valgrind again.

Yes, crash in  plaintext for 56 pinned server 8 thread each, this is why orm cached_queries not executed at all.
Error is
malloc(): invalid next size (unsorted)

I also this this is out heisenbug - so I keep all "as is" for a next round

MR 8949 is ready:
- upgrade mORMot2 to 2.2.7414
- added /cached_query implementation for raw server
- increased threads count for async server cpuCount * 2 -> cpuCount * 4

Now it compiles, all test except update passed, but for /update (and /rawpdate) ftb validation are not passed. 

  FAIL for http://tfb-server:8080/updates?queries=501
     Only 1 items were updated in the database out of roughly 500 expected.
     See https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#specific-test-requirements
   PASS for http://tfb-server:8080/updates?queries=20
     Executed queries: 10752/10752
     See https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#specific-test-requirements
   PASS for http://tfb-server:8080/updates?queries=20
     Rows read: 10635/10240
     See https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#specific-test-requirements
   FAIL for http://tfb-server:8080/updates?queries=20
     Only 506 rows updated in the database out of roughly 10240 expected

@ab - can you imagine what could have happened? The methods themselves have not changed... (Sorry, I'm not able to debug at the moment, only run tests in docker)

I'll do MR with the latest changes..

As for `q=`, I tested this case a year ago and it gives nothing. I'm afraid that even if we do this, we will get a ton of criticism, just like with Server-Name. I'll make it a separate MR (after MR with a latest changes)

About `using a modulo of the connection ID` - but what if we have 1001 client - we can`t use one connection for both 1 and 10001 .  As far as I remember I test an implementation with per-worker connection (call  ThreadSafeConnection once and memorize it into worker context) and performance is near the same as with ThreadSafeConnection

BWT currently our raw server creates 448 DB connections (num servers=56, threads per server=8, total threads=448, total CPU=56, accessible CPU=56, pinned=TRUE, db=PostgreSQL), maybe I'll increase `threads per server' to 10 to get 560 connections, so each concurrent client will have its own - that might work (after MR with q=)

@ab - it seems escaping is broken in latest Mustache implementation
Valid fortune resp should be  (<script&gt)

<tr><td>11</td><td>&lt;script&gt;alert(&quot;This should not be displayed in a browser alert box.&quot;);&lt;/script&gt;</td></tr>

but current implementation do not escape {{ }} template and result is

<tr><td>11</td><td><script>alert(&quot;This should not be displayed in a browser alert box.&quot;);</script></td></tr>

One more observation is that may-minihttp, ntex, and xitca-web use mimalloc. I also plan to try to use it in one of the next rounds. I've already tried mimalloc on my server - performance is the same as with libc alocator, but on the new TFB hardware it might change the numbers a bit.
P.S.
#6 is a good place IMHO

Thanks a lot! BTW new binaries can be released with SQLite3 3.45.1 (where JSON and read performance improvements are introduced)

I found this commit in sqlite3 build what replace all symbols pthread->_pthread + dl->_dl and issue #211
To solve my problem I do a backward replacement, and now linker is happy.
Linux script what do a replacing is here

Still do not understand why it compiles in mORMot2.

I doubt what is being measured - 1024 loop is too small.
I increase loop to be measured

for (i = 0; i < 1024*1024*1024; i++)

and create 2 program - one what call library from c, and one - from pascal (as you provide) - the results is the same

$ ./forloop_c.out
space 129340 clock_t value -536870912 

$ ./forloop_pas
space 129318 clock_t value -536870912

It is not easy here, in Ukraine, but this winter is so far easier than the previous one - we were ready for the russian terror.

As for TFB, let's look at the new HW. It's a shame that our last commit didn't play on the old HW - we don't have a base for comparison. After one run on the new HW, I plan to switch our test to mormot@2.2 (and possibly change threads/servers). Life goes on..

PR 8612 is ready.

/cached-queries memory issues occurred too rarely (once per 10 TFB run) - I also can`t reproduce it on my environment

As for the performance of single select, I'm afraid that the only way to improve it is to switch the Postgres connection to non-blocking mode (PQsetnonblocking).
But IMHO this requires a huge rework of the framework to become event driven:
- we need a .NET-like pool of database connections (with minimum and maximum size) that is not based on the thread ID (threadSafeConnection), but manages a list of all connections to one database and can provide the user with an unoccupied connection (or block if all connections are busy)
- Ideally, the database connection sockets waiting for the result should be in the same epool as HTTP sockets, so we need a callback-based event loop backed by an epoll (like in libuv). This is a complete redesign of the current HTTP server architecture

Another IMHO:
  An event-driven, callback-based architecture is the only choice we have with FPC. But it's a road to callback hell. I know very well what this means because I worked with callbacks in early JS for 5 years, up until Promises. Any complex logic based on callbacks is hell.

So my suggestion is to stay where we are. After all, we are now in the top 3 for ORM, and our code is production-ready unlike many others on TOP

Nice finding, for shure. Sometimes Pascal is unsafe....