Re^11: appending to html at beginning (don't use CGI.pm)

Thanks for following up. I should point out this is the opposite of what I was talking about in the other thread when I said that CGI should use PSGI as its interface layer. This is, or flavors of it, is what I meant–

use strictures;
use Plack::App::WrapCGI;
Plack::App::WrapCGI->new(script => "./my.cgi")->to_app;
[download]

There is zero functional/feature/middleware benefit to going the other way: PSGI->CGI.

You’re timing webserver responses… it’s hard to guess what’s up there. It’s also hard to measure such a trivial use meaningfully (it is like benchmarking “hello world”). I just sank about 45 minutes into trying to do a pure backend/perl benchmark but I’m having trouble getting part of it to act right and I’m outta gas and IQ.

Comment on Re^11: appending to html at beginning (don't use CGI.pm) Download Code

Replies are listed 'Best First'.
Re^12: appending to html at beginning (don't use CGI.pm) by hippo (Archbishop) on Mar 03, 2017 at 09:57 UTC
You’re timing webserver responses… it’s hard to guess what’s up there. Actually, my interpretation is pretty simple - using Plack in this way is necessarily more burdensome than not. The webserver response times everything from receiving the request to sending the response, ie: compilation, arg processing, handing the output back to Apache, etc. all of which might be faster or slower with one method or the other. The only surprise to me back then was the scale of the difference. I'd hoped for maybe just a factor of 2. It’s also hard to measure such a trivial use meaningfully (it is like benchmarking “hello world”). That's exactly why I did it this way (as alluded to above). With such a trivially simple script the differences in the runtimes should be as near as possible to the entire difference of using Plack versus not with no other complications. Obviously the percentage increase with Plack will reduce for scripts which do more but one can expect the mean penalty on my test rig to be about 70ms. The advantage of quoting a percentage difference for a trivial script is that the percentage should be in the same area for anyone performing this test regardless of CPU speed, disk speed, etc. If I just said "it's 70ms slower" that would differ wildly from what others see. Thanks very much for pointing out the possible use of Plack::App::WrapCGI. Unfortunately, if I run your sample script using the vanilla CGI script from my benchmark as the script argument to `Plack::App::WrapCGI->new` I get no output at all - not even any headers. I think this might be running it as a PSGI application which would then need further Plackage around it to turn it back into CGI? More reading required at this end, I fear.	[reply] [d/l]
Re^13: appending to html at beginning (plackup wrapcgi apache modperl registry) by Anonymous Monk on Mar 03, 2017 at 10:26 UTC
Hi I was confused I thought you were saying cgi-bin is faster than plackup, not plack is slow under cgi-bin I don't see why that would be surprising, "plack" loads a lot of modules (~97 to Moose ~117) thats going to take extra time Thanks very much for pointing out the possible use of Plack::App::WrapCGI. Unfortunately, if I run your sample script using the vanilla CGI script from my benchmark as the script argument to Plack::App::WrapCGI->new I get no output at all - not even any headers. I think this might be running it as a PSGI application which would then need further Plackage around it to turn it back into CGI? More reading required at this end, I fear. Wait a minute, you're trying to use wrapcgi to run plack under cgi-bin again? Um, thats not the purpose of it The purpose is to run a "vanilla cgi" as a persistent process, not under cgi-bin Think of plack/wrapcgi like Apache::Registry or ModPerl::Registry for your regular old fashioned cgi-bin scripts As long as you write them well (as per CGI to mod_perl Porting. mod_perl Coding guidelines, like using CGI::Application or ... ) then they should seamlessly run under mod_perl or plack, and run faster	[reply]