Some thoughts about Multi-threading in Sage CRM

I have been asked about the use of Multi Threading in Sage CRM. I think we need to understand where 'multi-threading' enters the equation. Please note that this is my understanding and I am happy to be educated via the comments.

Sage CRM can be imagined as having a 3 tier architecture or layer. A presentation layer - within the browser, the application layer in the webserver, the data layer in MS SQL Server.

Each request passes through the various layers as a single ‘Thread’. Multiple requests can be handled by both IIS and Tomcat Webservers. And IIS can use multiple Application Pools which in turn can handle multiple request. Within the Web and SQL servers the Requests can be multi-threaded’ but this is not controlled by CRM. This is something that is native to the webserver and to the database server.

We can imagine this as multiple users who connect to the Web Server(s) to make requests (Sage CRM can be deployed over multiple web servers). The Web Server in turn queries the SQL server which if required will send a response to the User. And depending on network architecture, the requests can pass the Load Balance routers that allow multiple physical servers to be used.


A browser uses principally JavaScript and HTML - JavaScript is a single threaded language. There is a thing in HTML 5 called a 'Worker' but our current design doesn't make use of this - we have a design in the browser that assumes sequencing of requests. Even within something like the Interactive Dashboard that make ostensibly asynchronous requests these are actually fired sequentially. Each gadget in turn makes their request.

Web Server

The Web Server does support threading. See:

IIS employs multiple threads to synchronize work. But these represent different threads created for the different sessions accessing the web server - so 10 people accessing IIS will create 10 ISAPI sessions and threads within IIS. BUT each thread then will contain a queue for the requests that each client is making to the server.

How the physical processes handle these processes is an additional question. Delphi (used for our eware.dll) as a language supports multithreading but the eware.dll would be only receiving sequential requests via the ISAPI.


If the server computer on which SQL Server is running has multiple CPU's then MS SQL Server can run a single query in parallel using multiple threads. The SQL server itself is a good judge of whether a query can be run in multiple threads or not. The query optimizer sees if parts of the query can be run in parallel and takes a call.​

In addition to running user queries on multiple processors SQL Server can also use multiple threads to build indexes. ​

If there is a performance issue the CPU itself may not be the bottleneck. Performance is more likely to be slow due to I/O constraints that can be sorted out by correct indexes. ​