Web clients can slow down server performance

[D-i-t-gh]

Hi,
I've set up a benchmark script that sends 1000 messages over multiple worker threads to my Mailpit instance. I made the test while the Mailpit UI was opened in multiple browser windows. The benchmark script sent the messages to Mailpit over the local network, and at the same time the client PC's browser accessed Mailpit over the internet. The client PC has a weak 2 core CPU. These are the results:

Test Case	Throughput
1 client PC / 1 browser window	67.42 msg/sec
1 client PC / 8 browser windows	10.24 msg/sec

Unfortunately this had a big impact on the server performance, which is not ideal especially in enterprise environments.

I made another test after I disabled the access to /api/events in our reverse proxy. In the browser, I could see the message Unable to connect to websocket, disabling websocket support. Now, the browser windows count doesn't have any impact on the server performance. However, there are no automatic UI updates any more.

In issue #319 the author recommends to switch to a polling mode after Mailpit detects that there is no websocket support. I have another idea - implement a lightweight polling mechanism, e.g. every 15 seconds (or maybe some kind of smart stateful polling), that will compare the current message count on client and server, and if different show a red point somewhere near to the message count (and maybe also in the tab header) to notify the user. The user can then click on the refresh button to synchronize with the server.

With this notification we could deactivate websockets to make it less probable that clients slow down the performance, and also the users without websocket support would benefit. What do you think?

[axllent]

Hi @D-i-t-gh - thanks for the message, this is a good question. Websockets are supposed to be really light weight, in fact the implementation itself should be much lighter than refreshing / polling. From my brief investigation, I think I know the reason for your slowdown though....

Just to clarity, you said "the client PC has a weak 2 core CPU" - I think you mean the server PC? Assuming this is correct (it's a weak server), you are likely expecting a bit too much from an old PC with 8 clients connected ~ while hammering it with messages :) It's also definitely not an "enterprise environment" either. But regardless, Mailpit is intended to be lightweight, and the slowdown issue you are experiencing is most likely due to Mailpit compressing every websocket message individually per client, rather than once for all clients.

I have made a small chance which will compress once per message, not once per message per client, so you'll get 8x less compression happening. I suspect this should boost your performance considerably. The feature is currently only available in git (develop branch), and in the axllent/mailpit:edge Docker image, but should be released by the end of the weekend.

[D-i-t-gh]

Thanks for your answer. I think you're right that this is probably a bit too much load for the test system :) There is also Defender constantly using CPU on the weak client PC and the connection runs through a VPN, so my test results are probably not very helpful.

I tested your edge build, but I didn't notice a difference. However, this is probably due to my special setup. I think your code change makes sense.

One thing comes to my mind when you mention compression - we use these settings and experience the best performance:

• MP_COMPRESSION=0
• MP_DISABLE_HTTP_COMPRESSION=true

So we turn off all compression where possible to reduce the pressure on the CPU. I think it would help us to have the possibility to disable compression for websockets too, as we run multiple instances of Mailpit which together process about 25k messages per day, and almost all messages are rather small (appr. 20 KByte).

[axllent]

You're 100% correct, I hadn't even considered to apply the global HTTP compression setting (MP_DISABLE_HTTP_COMPRESSION) to websockets. Done, this has now been added in develop / edge, and will be in the next release as well. This should reduce the load on your CPU too.