On 6/5/2017 7:21 AM, Warren Young wrote:
On Jun 3, 2017, at 4:13 AM, hw hw@gc-24.de wrote:
Perl is pretty fast, and most of the work is being done by the database, so I´m not sure how using an alternative to CGI could make things go faster.
There are many reasons CGI is relatively slow.
If you have many connections per second, you need a parallelizable technology to make things go fast. If everything chokes down to a single thread, you’ve got a serious bottleneck when the CPS count gets high enough.
CGI re-launches the cgi-bin/* programs on every page hit. Since Perl doesn’t leave behind “compiled” forms of the program as some other dynamic languages do (e.g. *.pyc in Python, *.beam in Erlang) it has to do the entire re-compilation over again.
With FastCGI or Plack, the app remains running once launched, serving hit after hit using the same instance.
- A follow-on advantage from the above is that you also don’t have to re-establish other runtime resources like DB connections, file handles, application state, etc. You can just keep it in RAM and access it repeatedly on each hit.
But again, down below about 1 CPS, the differences cease to matter, unless you’ve got the sort of app where the difference between a response time of 50 vs 100 ms matters.
Along these lines, SpeedyCGI forms an interesting middle ground between apache-layer perl runtimes and simple CGI re-execution.
If your perl scripts are already mod_perl-safe or have been written with persistency in mind (properly preparing SQL statements, reusing handles, clean variables, etc.), a simple shebang exchange can give you quite a large performance boost, as you're trading an entire perl compilation and execution for a small C wrapper that connects to an existing perl runtime.
Although upstream hasn't had any changes to it in nigh 15 years, it's still right there and available in EPEL 7 as perl-CGI-SpeedyCGI. I'd suggest giving it a shot.
HTH, -jc