On 6/5/2017 7:21 AM, Warren Young wrote: > On Jun 3, 2017, at 4:13 AM, hw <hw at 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. > > 1. 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. > > 2. 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. > > 3. 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