81–87 of 87 posts
Surprised with the choice of Apache. There are better choices for serving CGI nowadays. The only reason for still running Apache is you have legacy cruft that requires Apache (like .htaccess).
Earlier quoted context omitted.
CGI is not anymore a major use case for Perl. The modern Perl web apps are built on PSGI and production deployment is as a long lived Perl process. I wouldn't be surprised to learn that Perl startup time has drifted. Need benchmark.
The major modern use case I know of is command-line utilities which also benefit from low start-up. Of course, that doesn't mean there hasn't been "perf rot" over the decades as you say. Such rot should never surprise anyone. :-) Some perl5 lover should take the time to compile all those 5.6 to 5.42 versions on the same host OS/CPU and do a performance comparison and create a nice chart for the world to trap and mayb…
zsh# rei=(chrt 99 taskset -c 2-3 env -i HOME=$HOME PATH=/bin)
zsh# tim=(-k2 -o14 -n14 -m14)
# Set 1
zsh# $rei tim $tim './perl-5.8.9I got my start in the CGI era, and it baked into me an extremely strong bias against running short-lived subprocesses for things. We invented PHP and FastCGI mainly to get away from the performance hit of starting a new process just to handle a web request! It was only a few years ago that I realized that modern hardware means that it really isn't prohibitively expensive to do that any more - this benchmark gets to 2…
I think you might have found that CGI scripts deployed as statically-linked C binaries, with some attention given to size, you might've not been so disappointed. The "performance hit of starting a new process" is bigger if the process is a dynamically-linked php interpreter with gobs of shared libraries to load, and some source file, reading parsing compiling whatever, and not just by a little bit, always has been, s…
- Keep-alive/pooled connections to remote services can significantly reduce average latency for making those calls.
- In-memory caches that allow amortizing repeated lookups across requests.
Just those two alone mean that a serious high performance server probably couldn’t get away with just CGI even ignoring startup time.
Earlier quoted context omitted.
(I didn't downvote you) plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully. The writes returned 3xx because the handler returns a redirect, so this is expected.
> plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully. HTTP load testing is a problem area that is much more subtle than it seems. I've no doubt that plow does what you're saying here, but, without any tests whatsoever, I have serious doubts that it does so correctly, particularly if/when the load test starts bumping up against any of the nume…
> Yeah, but, unless `plow` actually follows that redirect, it's not really measuring the actual end-to-end latency...
Not in this case, since the purpose here was to measure the POST (write) not the subsequent GET (read) that a browser would do after the redirect.