ISAPI DLL MaxConnections

[Mark Williams 14]

The default MaxConnections is set at 32 for TISAPIApplication.

 

I have no idea how many people may be calling my dll at any given time. 32 seems to me to be too low a number. I have set it to 200.

 

I cannot find any advice as to best policy on setting this value. The help file simply says to test the ActiveCount and InactiveCount and adjust accordingly. That is going to be a little difficult to test.

 

I don't want to have exceptions flying off because of MaxConnection exceeded and likewise I don't want to degrade performance.

 

If, for example, I set MaxConnection to 1000 I assume that will not of itself degrade performance and that there will only be issues when actual connections are that high,

 

If that is right then it seems to me that slightly deteriorated performance is preferable to exceptions due to exceeding max connections.

 

Or am I missing something?

[Attila Kovacs 629]

44 minutes ago, Mark Williams said:

I set MaxConnection to 1000 I assume that will not of itself degrade performance

you are right, it wont.

this is all what happens:

 

  if (FMaxConnections > 0) and (FAddingActiveModules >= FMaxConnections) then
    raise EWebBrokerException.CreateRes(@sTooManyActiveConnections);

 

Calculating the max allowed concurrent user depends on many things and there is no exact formula.

You could do some stress-test to see how the server works under load.

This would also test how your dll and connection pool are performing, are there deadlocks, unexpected behavior, etc...

 

 

[stijnsanders 35]

I would consider setting this to 0. Unless you're sure you want your web service to halt when there are a lot of people at once, which seems like the very thing you'd like to avoid.

In the work I've done with ISAPI (not using Delphi's own TISAPIApplication though, sorry) I just keep queueing incoming requests in a queue the thread-pool can take from with any worker thread that happens to be available for work...

(Though I seem to have written a comment there to consider doing something when there's a lot of incoming requests...)

The rationale would be that other things would fail first before your thing does: memory runs out, or network sockets run out, or IIS runs out of execution contexts (and throws 503 itself when it deems appropriate...

[Mark Williams 14]

On 1/30/2020 at 3:57 PM, stijnsanders said:

I would consider setting this to 0

I'll give that a try and see how it pans out.

 

On 1/30/2020 at 3:57 PM, stijnsanders said:

I just keep queueing incoming requests in a queue the thread-pool can take from with any worker thread that happens to be available for work...

I thought this was more or less what iis does with the dll.

[stijnsanders 35]

Ah well, IIS does its own thread management, that's right. And you have a choice: You could do all the work for a request in the HttpExtensionProc call you get and return HSE_STATUS_SUCCESS, it works really great for small responses and when it's pretty clear what the extension is supposed to do, and each request won't take too much time of a worker process. But, if you want do have more control over threads, over different kinds of things happening depending on the requests that come in, and especially keep threads free when they're waiting on other processes, the best you can do is return rightaway with HSE_STATUS_PENDING, and manage the threads to do the heavy lifting yourself. The threads IIS uses to call your HttpExtensionProc, aren't supposed to run for long times, and probably are also limited in number and will cause 503 errors when they're all occupied. If you want to keep IIS responsive and have more control what happens when a really big stream of requests is hammering the server, I strongly suggest HSE_STATUS_PENDING.

 

Well, actually, I would suggest you try some other options as well. I've been working with something one level down: HTTPAPI. There's a little thing called http.sys which (modern) IIS uses itself to do the actual requests. And the API is open for us to use as well. If you're sure you actually don't need much of the overhead IIS offers (strong security, filters, access control, logging, etc.) or are confident you can do it (better?) yourself, check it out.

 

Also there are open-source alternatives to web servers as well. And there's much more than Apache httpd out there if you care to look. (Yes, done that) I've been able to do CGI and SGI with some of them, but not FastCGI (yet?) mainly because I really dislike how the protocol was designed. NginX is making a great name for itself as a server that's particularly fit to configure for heavy loads. And I've also played around a bit with Lighttpd.

 

And — if you really, really — feel fit for the challenge, you could always try to roll your own. I've gotten the best of heavy load results with that, but that really is eliminating overhead done to the max. (And also I haven't been able to put much time into that project since a while before HTTP v2 is out, and HTTP v3 is around the corner...)

[Mark Williams 14]

On 2/4/2020 at 11:30 PM, stijnsanders said:

Ah well, IIS does its own thread management, that's right. And you have a choice: You could do all the work for a request in the HttpExtensionProc call you get and return HSE_STATUS_SUCCESS, it works really great for small responses and when it's pretty clear what the extension is supposed to do, and each request won't take too much time of a worker process. But, if you want do have more control over threads, over different kinds of things happening depending on the requests that come in, and especially keep threads free when they're waiting on other processes, the best you can do is return rightaway with HSE_STATUS_PENDING, and manage the threads to do the heavy lifting yourself.

Thanks. I'll look into this at some point. However, my ISAPI dll isn't really designed to do heavy lifting. Just user validation, configuration settings and downloading of smallish files. 

 

There is occasionally a need to upload/download largish files and this is something I am planning to move to FTP or maybe there is a better/faster solution?