mORMot Open Source

emk

Member

Registered: 2013-10-24

Posts: 96

mORMot - Windows (http.sys/FastMM4) vs Linux

Reading topic Thanks to all for mORMot/Zeos + Linux!!! makes me wonder what are speed/advantages differences between Windows(Delphi) and Linux(FPC).
Many people are not familiar with Linux(including me) and I think this topic can shed some light. Besides Windows requiring a license:

- speed differences: Windows has a very fast "http.sys" and "FastMM4" memory manager, Linux? (I know FPC has some slower MM)
- general speed differences;
- threading: "http.sys" spawns some fixed worker threads who process many connections, what about Linux, every connection has it's own thread?
- websockets: the same question
- proxy: can be put directly on web or needs a proxy? (I'm asking for both OS-es. Any penalty?)
- any other difference worth mentioning.

Thank you.

Last edited by emk (2020-03-28 21:17:05)

danielkuettner

Member

From: Germany

Registered: 2014-08-06

Posts: 330

Re: mORMot - Windows (http.sys/FastMM4) vs Linux

- speed differences: Windows has a very fast "http.sys" and "FastMM4" memory manager, Linux? (I know FPC has some slower MM)
- general speed differences;

I can't give you technical answers, but my project feels a little bit slower under Linux. But I haven't analyze why or what's the reason for it. (FastMM4 could be better in case of bigger data transform to RawUTF8, but it's only a guess).

Http.sys could be faster, but in real projects the bottleneck are always the DB (MongoDB in my case). MongoDB is very fast, but 10 msec are much more than a plain http request, so differences here can only measure in test cases.

- websockets: the same question

I didn't use it. But under Win you can't benefit from http.sys here, so linux should be faster.

- proxy: can be put directly on web or needs a proxy? (I'm asking for both OS-es. Any penalty?)

I've used apache from the beginning as a proxy for my Windows service. Now I need only one Linux machine. I used also only one Windows machine with apache and ldap under Windows. For smaller companies with smaller DB sizes it's near the same and possible in production.
But it's not a must.

- any other difference worth mentioning.

Many years ago (at 2000) we turned away from microsoft to Linux and FreeBSD. On server side Linux/BSD was better, faster, much more stable and all for low costs. You are more independent.

I think this arguments still exists today.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,220

Website

Re: mORMot - Windows (http.sys/FastMM4) vs Linux

For server-side process, and Linux/Windows comparison.

1. Our framework tries to avoid memory allocation as much as possible. And FastMM4 was in fact not good with multi-threaded process. FPC heap is slower in single-threaded apps making a lot of memory allocation, and consume more memory when a lot of threads exist, but tends to be very stable and efficient for server process. We tried alternatives (like palloc/clib or Intel tbb or jmalloc) and FPC heap was the more stable with less memory consumption.

2. We wouldn't put a mORMot server directly serving data on port 80/543. We always use nginx as reverse proxy, running on the localhost. Then set HTTP/1.0 connections over Unix Sockets to one or several mORMot server running MicroServices, with its thread pool. With this pattern, performance and scalability are very high, and we served for instance billions of requests (and TB of data) on a Debian server for more than 10 monthts without restarting our service. We just restarted nginx to have the Let's Encrypt certificates renewed. Nginx served also all static content (e.g. plain html/js/css/pictures) so CORS security was easy to do: you can share a same host name, and assign URIs to each microservice or content. Nginx behave like http.sys URI registration in this aspect, with easier configuration IMHO.

3. Linux has a lot of advantages over Windows for hosting services. One is its performance, especially about file access: SQLite3 and most DB are more than twice faster when running on Linux than on Windows. And Linux is much smaller, less frequent and without breaking updates, no antivirus required, simple to harden....

4. HTTPS is a requirement today. Let's Encrypt is much less integrated on Windows http.sys... due to this reason, and also because hardening a Windows server is hard, most of my Windows server configurations where behind a Linux/BSD gateway running nginx or haproxy, and Windows was in another machine. Putting a Windows server over the Internet is a risky business; it should rather be isolated in a private network. Such a remote communication (even between VMs) did have a cost, so performance was lower than a mORMot+nginx over unix sockets on localhost.

5. Windows and http.sys are great if your server should run locally - on an existing Windows IT system. But for hosting mORMot servers in the cloud (or you own private VM/server), Linux is a much better approach.

6. For Windows + http.sys servers, we made a relay feature a few weeks ago: you have a local mORMot server for most of your clients running on the local corporate network. Then you have a Linux box somewhere running our SynProtoRelay asynchronous server, and your remote clients (mobile/desktop from home) are able to connect to this relay and access the data without messing with the corporate IT policy.

emk

Member

Registered: 2013-10-24

Posts: 96

Re: mORMot - Windows (http.sys/FastMM4) vs Linux

Thank you very much. I'll investigate when I have some time.

What aboutL

- threading: "http.sys" spawns some fixed worker threads who process many connections, what about Linux, every connection has it's own thread?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,220

Website

Re: mORMot - Windows (http.sys/FastMM4) vs Linux

Our Linux HTTP server has a thread pool for HTTP/1.0 not kept alive connections. It only creates a thread per client for HTTP/1.1 kept alive connections, or websockets connections.

This is why we use nginx as front end, which severs HTTP/1.1 or HTTP/2 over TLS, but create small HTTP/1.0 requests over Unix Sockets (faster than TCP sockets) to the localhost mORMot server.
So this configuration is able to maintain hunderths of thousands of concurrent connections, with very high stability and performance. It is better to let nginx handle any potential attack (like DOS attacks) than our own HTTP Server. Mitigating DOS attacks is very difficult, and expects complex, multiple and always evolving mitigation algorithms. This is safer to let nginx doing its stuff - and keep our MicroServices focusing on its data.

And for high demanding tasks, we prefer barebone HW servers, even cheap one, rather than VM, which have to share CPU and resources, so are less stable.

I would like to rewrite our HTTP server in the close future, to allow HTTP/1.1 and even more websockets connections be fully thread-pooled.
The logic refactoring was started for HTTP and WS, and we already have a cross-platform event-driven sockets server class available... I guess it will be part of mORMot 2.

emk

Member

Registered: 2013-10-24

Posts: 96

Re: mORMot - Windows (http.sys/FastMM4) vs Linux

1. Please include all this info in a blog post or in manual.

2. Brilliant idea, especially for the websockets:

I would like to rewrite our HTTP server in the close future, to allow HTTP/1.1 and even more websockets connections be fully thread-pooled.

- can be thousands of websockets JS clients who waits for notification;
- or another scenario for multi tenancy database, every office server(can be thousands, every tenant with his office-server) must be connected 24/7 to web-relay-server waiting for notification of incoming call

Last edited by emk (2020-03-29 14:22:26)

mpv

Member

From: Ukraine

Registered: 2012-03-24

Posts: 1,539

Website

Re: mORMot - Windows (http.sys/FastMM4) vs Linux

+ for all ab's arguments.

For me the worst in http.sys (may be one of the main reason I migrate to Linux) is the fact what http.sys is a kernel level driver and any vulnerability there (every year new one and this is endless story) give attacker a System account. Just google "http.sys vulnerability".

Windows updates is another story (require reboot, sometimes took too long time, etc etc).

About performance: even if something works not as fast as we need then for performance turning under Linux we have a perfect toolchain: perf, strace, valgrind, so we can find and optimize exactly peaces of codes what runs slow.

Last edited by mpv (2020-03-29 17:42:19)