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
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
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.