How IIS Allows for Better Server Resource Utilization
The Alpha Anywhere Application Server for IIS is currently in beta. For more information on IIS, and how you can become a beta tester, check out our recent overview webinar.
Scaling Across Multiple Processors
Web applications running in Alpha Application Server for IIS default to running up to five processes and can therefore automatically scale across multiple processors. This provides better utilization of server resources
The Alpha Anywhere Application Server for IIS uses the same Xbasic engine that the current stand-alone Application Server uses and thus behaves in the same way. Xbasic statements are executed one at a time. The Xbasic engine uses a combination of narrowed affinity and a critical section to make sure that two different threads do not enter the interpreter at the same time. Much of the internals of Alpha Anywhere Application Server are native implementations, however, and are not subject to this restriction. Where possible, the server actually does run in parallel in multiple threads and on multiple CPUs.
As a simple example, when a request for an .A5W page comes in, the Application Server locks the Xbasic engine to process that page. This means another request for an .A5W page has to wait until the other page is finished processing before it will be processed. When processing is finished the Xbasic engine is unlocked and the processor affinity is widened.
In a more common example an .A5W page would have some operation like database access, socket processing, or file I/O. When this type of operation happens the Xbasic engine lock is released freeing the Xbasic engine to do other work such as processing another .A5W request. When the first request’s operation is finished it will wait for the Xbasic engine availability and then continue/finish executing the .A5W page.
There are other products that have similar limits too. For instance, Node.js handles requests on a single thread. There are load balancer configurations usually using nginx with multiple instances of Node.js running on the same machine so that all the cores can be used on a single machine.
IIS’ Web Garden
IIS does make it easier to run Alpha Anywhere Application Server for IIS behind a load balancer, but IIS has something else called a Web Garden. You can think of this as a mini load balancer. A web application can define how many processes it uses and IIS automatically routes requests to a process that is not busy. This is transparent to the application. The number of processes that an application uses is set in the publish profile in the Alpha Anywhere Developer Edition and it defaults to 5. Each process is another instance of the application server which means each process has its own Xbasic engine. Each instance has a narrowed affinity to a specific logical processor. With a default of 5 processes this means that 5 concurrent requests can be processing Xbasic at a time.
IIS’ Web Garden removes the need of load balancer to control multiple processes on a single machine. Additionally, you wouldn’t need AlwaysUp either because IIS is the supervisor process for site and web apps defined in it and IIS will keep your sites/apps up and running. You can even configure your web apps so that IIS will proactively restart them based on various conditions like once a day or when memory usage exceeds a limit. This is configured in the web app’s application pool recycle settings.
To take this a step further, where web gardens allow you to scale with a single machine, web farms allow you to scale across many machines and load balance across those machines to boot providing even more scalability and reliability. IIS make this straight forward to do and the Alpha Anywhere publishing profile settings allow you to configure your web app so that it is ready to be used to scale across many machines in a web farm.
IIS gives you better operational control over your web apps and gives you more options to allow you to get better utilization out of the computing power that you have.