Forum > Networking and Web Programming

Application.Threaded in web applications

<< < (2/2)


I really appreciate your kind explanations. I'm not a genuine computer scientist and do not know much about outside language itself.

Sometimes I felt CGI remains in memory, based on... difficulty to explain, but values for uninitialized variables or response delay, etc. Cache could be an explanation.

1 ms for user is nothing. But in our country we have many booking sites of tickets. Hundred of thousands try to connect to the site at the moment of opening (e.g. 10 am of  a specific day).  One millisecond per request is nothing but it may delay server seriously if a large crowd gather at the same time.

My webserver will not collect hundreds of thousands at one time, but I have to think up to several hundreds.

Still I don't mind the performance differences yet -- as I told, CGI is doing its job well. I'm looking around other approaches for next step. Currently I'm testing FCGI model with just single concurrent instance.  It will process requests one by one (I hope) --- so do not need multiple processes nor threads.

I've set up a FCGI model, with a datamodule having database access and relevant methods. There is another TFPWebModule with treats requests. This web module is created for every request (I talked on this at another post regarding wkPooled or wkOneshot) but data module is not. The new routing system of fpweb, which does not need TFPWebModule, may be better. It does not have to re-create anything for every request.

Again really thank you very much for your advices.

In a sense thread shouldn’t necessary. Webserver (IIS, nginx, etc) should spawn new instance if necessary.

Not necessarily, the idea behind fast CGI is that you have your fast cgi application running in the background listening to incoming requests to handle them seperately. They kindof work like a very limited webserver.
As such process management must often be done individually. For example from the nginx wiki:

--- Quote ---Unlike Apache or Lighttpd, NGINX does not automatically spawn FCGI processes. You must start them separately. In fact, FCGI is a lot like proxying. There’s a few ways to start FCGI programs, but luckily PHP5 will auto-spawn as many as you set in the PHP_FCGI_CHILDREN environment variable.
--- End quote ---

Some webservers like Apaches mod_fcgid spawns the respective number of fast cgi processes.
So it heaviely depends on the webserver.

This is why PHP nowadays has the so called PHP FastCGI Process Manager (php-fpm), which dynamically pools and creates instances of the FastCGI services. This way, the user just starts the fpm, and sets it as the target for the fast cgi passthrough in the webserver, and the fpm then spawns new cgi processes dynamically, this also allows configuration of the individual processes (so some processes only handle some requests with some specific configuration).

It can also be quite helpful to containerize your application, e.g. using docker, and then you can just spin up multiple docker instances if you need to handle more load. This is what I usually do when I write a web server application, as this also has a lot of other useful features (as resource isolation and ease of deployment)

You are right. nginx does not spawn new process itself. IIS seems to do that.


[0] Message Index

[*] Previous page

Go to full version