Recent

Author Topic: Application.Threaded in web applications  (Read 1075 times)

egsuh

  • Hero Member
  • *****
  • Posts: 1087
Application.Threaded in web applications
« on: January 26, 2023, 09:08:44 am »
Hi,

Following is the program file when I create a new FastCGI project.

Code: Pascal  [Select][+][-]
  1. program fcgiproject1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   fpFCGI, unit1;
  7.  
  8. begin
  9.   Application.Title:='fcgiproject1';
  10.   { Uncomment the port setting here if you want to run the
  11.     FastCGI application stand-alone (e.g. for NGINX) }
  12.   // Application.Port:=2015; // For example
  13.   Application.Initialize;
  14.   Application.Run;
  15. end.

And following is the program file when I create a new HTTP server application, with threaded on.

Code: Pascal  [Select][+][-]
  1. program httpproject1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   fphttpapp, unit1;
  7.  
  8. begin
  9.   Application.Title:='httpproject1';
  10.   Application.Port:=8080;
  11.   Application.Threaded:=True;
  12.   Application.Initialize;
  13.   Application.Run;
  14. end.
                                     

My question is, is  "threaded" not necessary/meaningful for FastCGI applications?  I'd like to run FCGI application on NGINX.


         

zeljko

  • Hero Member
  • *****
  • Posts: 1412
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Application.Threaded in web applications
« Reply #1 on: January 26, 2023, 09:42:25 am »
I don't know too much about fcgi and it's threaded abilites, but if you run it on unix likes eg linux then you should include cthreads (if you plan to use threads in your fcgi application).

Warfley

  • Hero Member
  • *****
  • Posts: 1071
Re: Application.Threaded in web applications
« Reply #2 on: January 26, 2023, 11:45:59 am »
Depends, do you want to be able to handle more than one request concurrently? If so you should use threaded.

It's a different story if you are compiling a (non fast) CGI application, where for each request a new process is started, which makes threading redundant.
I would actually recommend using CGI over fast CGI, because spawning processes on Linux systems is about as efficient as spawning a thread (in fact, for the linux kernel a thread and a process are basically the same thing). Also FPC applications are pretty lightweight, as they usually do not rely on many external dependencies (a pure fpc application does not even bind to LibC).

FastCGI was developed for scripting languages like PHP, because starting a new PHP process requries loading the complete PHP interpreter into memory, which is slow. You don't have that issue with native FPC, applications, so just go for CGI. It's the easiest way to implement a web application.

So my recommendation is, go for CGI and you don't need to care about threading

egsuh

  • Hero Member
  • *****
  • Posts: 1087
Re: Application.Threaded in web applications
« Reply #3 on: January 27, 2023, 10:22:04 am »
Quote
I would actually recommend using CGI over fast CGI, because spawning processes on Linux systems is about as efficient as spawning a thread (in fact, for the linux kernel a thread and a process are basically the same thing). Also FPC applications are pretty lightweight, as they usually do not rely on many external dependencies (a pure fpc application does not even bind to LibC).

Thank you very much for your comment. Currently I'm running CGI on Windows, but thinking moving to FCGI for following reasons. Actually my application does not need threaded in FCGI mode, as CGI is serving rather good. Just checking any difference between HTTP server and FCGI.

But regarding CGI and FCGI, I think as follows. Please let me know your idea on them, if any.

1) The difference between CGI and FCGI is not just between spawning a process or a thread. CGI must be loaded from HDD (or SSD) at every request, while FCGI remains in memory. Won't this cause rather large difference?

2) My webserver needs connection to Firebird database. DB connection takes long compared with other operations. So I'd like to keep DB connected even during idle time. This can be done only with FCGI.

What do you think?

Warfley

  • Hero Member
  • *****
  • Posts: 1071
Re: Application.Threaded in web applications
« Reply #4 on: January 27, 2023, 02:05:33 pm »
1) The difference between CGI and FCGI is not just between spawning a process or a thread. CGI must be loaded from HDD (or SSD) at every request, while FCGI remains in memory. Won't this cause rather large difference?
Your OS will cache frequently used files, meaning this should not be an issue. That said, spawning a process under Windows is quite slow (because each process gets a window assigned, which takes much more effort than under linux), so using threads for a windows host is actually much faster than starting a process (which is not the case on Linux)

2) My webserver needs connection to Firebird database. DB connection takes long compared with other operations. So I'd like to keep DB connected even during idle time. This can be done only with FCGI.
Database connections are (usually) not thread safe, so either you need to create access control through critical sections, which introduce a great overhead and might force serialize your theads, removing basically any advantage of threading, or you need to establish one connection per thread anyway.

Also don't pre-maturely optimize something that does not need to be optimized. A database connection will be established once every request, an a request, even with a very good network connection will take around 10-20 milliseconds just network travel time. If the database is running on the same network as the host, the connection will probably be established in less than 1 millisecond. Does it really matter if the user waits 20ms vs 21 ms for a request to finish?

egsuh

  • Hero Member
  • *****
  • Posts: 1087
Re: Application.Threaded in web applications
« Reply #5 on: January 27, 2023, 11:50:28 pm »
@Warfley

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.

egsuh

  • Hero Member
  • *****
  • Posts: 1087
Re: Application.Threaded in web applications
« Reply #6 on: February 02, 2023, 01:37:57 pm »
In a sense thread shouldn’t necessary. Webserver (IIS, nginx, etc) should spawn new instance if necessary.

Warfley

  • Hero Member
  • *****
  • Posts: 1071
Re: Application.Threaded in web applications
« Reply #7 on: February 02, 2023, 02:22:12 pm »
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.

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)

egsuh

  • Hero Member
  • *****
  • Posts: 1087
Re: Application.Threaded in web applications
« Reply #8 on: February 03, 2023, 09:17:48 am »
You are right. nginx does not spawn new process itself. IIS seems to do that.

 

TinyPortal © 2005-2018