Given that I'm creating a high transaction volume REST only web service, can you provide suggestions for reducing the Web Connection footprint? We plan to stick with COM based messaging (EXE Servers). We won't be using any of the HTML scripting functionality, no templates, no sessions, no cookies. We will need much of the Request object functionality, access to query string parameters, form-encoded post variables, raw post data (JSON only), and most of the Path methods. With the Response object, we will always reply with JSON data and specify certain header tags (mostly for cache control).

Considering all this, can you suggest what code we could do away with to reduce the size of our Server objects? Basically, we want a customized version of WC for REST only services.

Also, did I read somewhere that the number of concurrent servers is limited to 32? Our web server uses two Xeon E5-2650 V3 processors. This provides 20 physical CPU cores (40 simultaneous threads with Hyper-Threading). We are hoping to run 40 simultaneous Server objects. Is that possible?

Your input is much appreciated.

Wow that is going to be quite the machine, dare I ask what makes such high demands?

As far as stripping down WC, my opinion is you won't save that much and all you will be doing is making it harder on yourself to do updates when Rick releases a new feature you want to use. And if you do dismantle the core product you run the risk of removing something you don't know you need today but will will bite you tomorrow.

I'm sure Rick will have a more correct answer.

The application is ticket sales and, at times, can have very serious demands (and very upset people if those demands are not met).

Rob,

Not sure if pulling out a few libraries will yield much in the way of tangible improvements in performance for Web Connection. Remember that Web Connection runs as persistent servers so other than initial startup time (which for extra size is minimal) I don't think that will buy you much if anything noticeable. That said I think it IS a good idea to remove what you don't need just to get rid of the clutter in your projects.

The first place to look is wconnect.h and check off all the things you don't need to load. Then go into wconnect.prg and remove things that you don't need. Note a few - like the XML parser and config stuff are required, and of course the core libs plus wwUtils and wwAPI, but some others can go. Then use GoFish and look through the app for things you see in the project you think you don't need. Lack of refactoring tools in Visual FoxPro makes this tedious, but doable. A lean install (without user code) cna probably come down to about 700k or so.

Again I think this is nice for a cleaner project file, but I don't think this has much of an impact on performance or even load time.

Also, did I read somewhere that the number of concurrent servers is limited to 32? Our web server uses two Xeon E5-2650 V3 processors. This provides 20 physical CPU cores (40 simultaneous threads with Hyper-Threading). We are hoping to run 40 simultaneous Server objects. Is that possible?

No the server manager is limited to 32 instances. But are you sure you are going to need that many instances? Are your requests long running? That's really the only reason to run so many simultaneous instances and if that's the case then the better approach is to have other processes that can run in the background and handle the lengthy operations with callbacks to let you know when things are completed rather than trying to have so many servers.

If you really are that busy I can probably provide you a custom build, but I would really caution against having too many VfP instances running simultaneously as it'll slow down startup considerably.

+++ Rick ---

So I had to double check, but it looks like the Web Connection Module doesn't have any limitations on instance count. It's only the ISAPI module that is limited to a fixed number which happens to be 32.

Here's the sample application fired up under COM with 40 instances:

Seems to work OK, but loading for all those instances takes about 15 seconds.

+++ Rick ---

Ok, thanks for the advice and the testing of where the limits are. I don't know of any long running tasks in the application yet, but if we add one (e.g. reporting) at some point it may be advisable to reserve a few threads for background tasks. I assume your Web Surge Stress Tester will be a valuable tool for identifying any long running requests.

at some point it may be advisable to reserve a few threads for background tasks

There's no way to do this directly with Web Connection. The closest thing you can do is run long running requests in COM Singlemode which spins up new instances for the COM server that run outside of the pool. If you're running code on the same server anyway this is often a good enough trade off.

• Running long running Requests in Single COM Mode

+++ Rick ---

It seems you've got all contingencies covered at this point; the benefits of mature software. Thanks again Rick!!