Topic Summary - Displaying 4 post(s). Click here to show all
Posted by: Dandello Posted on: Mar 4th, 2019 at 4:00pm
Okay - According to what I have gleaned from reading about how to convert scripts to FastCGI, I doubt there will be any speed savings. This has to do with the fact that YaBB doesn't use CGI.pm for anything other than processing attachments. A look at FastCGI indicates it's trying to speed up things YaBB doesn't use - CGI.pm's templating ability (which is deprecated anyway).
(And with CGI.pm's templating being deprecated, people using that are being urged to move over to newer templating software such as Mojolicious or Plack.)
All of that said, some sources concerning FastCGI appear to say it SHOULD speed things up. So I'll need to do some experimenting.
But the real speed savings will come with saving things in 'real' databases.
FastCGI is a web server extension that allows you to convert CGI programs into persistent, long-lived server-like applications. The web server spawns a FastCGI process for each specified CGI application at startup, and these processes respond to requests, until they are explicitly terminated. If you expect a certain application to be used more than others, you can also ask FastCGI to spawn multiple processes to handle concurrent requests.
There are several advantages to this approach. A typical Perl CGI application has startup overhead for each request that includes the process of spawning a process and interpreting the code. And, if the code has a lengthy initialization process, that simply adds to the overhead. A typical FastCGI application does not suffer from any of these problems. There is no extra spawning for each request, and all the initialization is done at startup. Since these applications are long-lived, they allow you to store data between requests, which is also an advantage.
Has anyone considered making the YaBB Sources FastCGI fit?