Here is a list with five things that kill the performance of your IntraWeb application. Some more, some a little less, but together they have a huge impact and will determine if your application will be capable of serving thousands of simultaneous users or just a couple of dozens.
- Using Delphi built-in Memory Manager:
Whenever you are using the Delphi built-in memory manager (i.e. you are not using any particular MM), your application is very restricted by thread contention in the memory manager. Some benchmarks show that the application may perform 5x or more better when using a memory manager that performs better under heavy multi-threading.
If you haven’t read yet, I strongly recommend you to read this blog post carefully:
IntraWeb now offers 3 different memory managers that are simple to use. We recommend that, in development you always use the FastMM4.992 version (or FastMM5 in case you have a license, of course) in FullDebugMode so it will catch any memory leak. In production, you can pick any of the 3 that suits you better or even a 3rd party memory manager.
- ServerController.HttpKeepAlive = False
The HttpKeepAlive property controls whether the HTTP(S) server will close the connection (with the browser) after responding to a request. In general, all the browsers will send an HTTP header like this:
HTTP/1.1 200 OK
Connection: Keep-Alive
with every request. This means that the server can (and should) keep the connection open. Estabilishing a new connection is expensive and affects the performance, that’s why it should be kept open.
Historically, the default value in IntraWeb is False because of problems with various versions of Internet Explorer in the past when HttpKeepAlive was set to True. But the general recommendation for performance has always been using HttpKeepAlive = True. Now that Internet Explorer is dead and buried, you should double check this property and set it to True. Eventually we are going to change de default to True.
- Delpoying the debug build
Yes, I’ve seen many times developers deploying a build that was built using de “Debug” build configuration. Debug configuration by default does not optimize the code and uses the debug version of Delphi VCL/RTL which generally performs worse than the release version. Always make sure to deploy a build built with the Release build configuration.
- ServerController.Compression.Level <> 1
IntraWeb uses an optimized version of gzip that performs really well when Compression.Level = 1. Setting it to any value higher than that causes the HTTP compression to take longer and uses more CPU cycles. It will compress the content a little more (especially HTML, JavaScript and CSS), sure, but the benefit isn’t worth it. Unless you have a very specific scenario (e.g. a super slow browser <-> server connection where each transmitted byte counts).
On the other hand, disabling the HTTP compression will make your server a little faster, after all it won’t need to compress the output, but it will make the application appear to be slower on the browser side. It will take longer to transmit the content and the general perception will be that your application takes longer to load, especially if you have many external JavaScript libraries. So, setting the compression level to 1 is the optimal choice.
- JavaScriptOptions.UseUncompressedFiles = True, JavaScriptOptions.Debug = True
These ServerController options exist for debugging when you have any issues with JavaScript code. It helps developers to identify the cause of the problem. This should never be set in production. When generating a production build, always set both to false.
Except issues (1) and (3) above, all the others can be dynamically set/controlled loading the ServerController configuration from an ini file, which is done automatically whenever you set AutoLoadIniFile to True (in the ServerController itself)…. and you don’t need to write a single line of code to use that feature.