Warren Young wrote:
On Jun 2, 2017, at 5:05 AM, hw hw@gc-24.de wrote:
Warren Young wrote:
There are various options. We use mod_fcgid + Plack here.
I need to look into that when I have time.
I wonder if it wouldn’t have been faster to just backport the app to Perl 5.16? How hard could it be? It’s not like Perl 5.16 is a hopelessly lame and incapable language.
It would be possible. There are reasons to use that feature, though, and those reasons remain.
The recommendation to replace mod_perl with mod_fcgid comes from the RHEL 7 release notes: http://goo.gl/fZxHw9
After sending that message, I remembered that we rejected that option once we found out that when you build your app under Plack, it serves content via a Perl web server using a standard interface called PSGI. That Perl web server normally binds to localhost on a high-numbered TCP port, so we just stood Apache up in front of it as a reverse proxy. That avoids the security hassles of binding to TCP port 80, and it lets us foist the static content serving load off on Apache, so that the Perl layer serves only dynamic content.
There are many PSGI-aware web servers:
http://plackperl.org/#serversThe default used by Plack is HTTP::Server::Simple, which is probably fast enough for your purposes if CGI remains appropriate for your app.
If you were already trying to get off CGI to make the app faster, many of the alternatives in that list will get you that speed.
The mod_fcgid method may be easier to port to, since you’re already using CGI, however.
I have no idea. I´m not a web developer, so I´m using CGI as a simple means for the users to use the programs, with a few of the advantages a web browser offers for displaying stuff. There are less than 10 users.
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. Apparently it´s possible to save the overhead of compiling the perl programs and of opening connections to the database for every request. Currently, it is questionable if things would go so much faster as to be worthwhile spending days or weeks on changing and debugging a working system.
Test have shown that lighttpd apparently is somewhat faster than apache2
This is generally true only at fairly high loads, up in the thousands of connections per second. Distinguishing this also requires that the bottleneck be in the web server, not in the web app it’s serving.
I simply had the impression that responses came faster, with me being the only user. So what would speak against using lighttpd?
Since your app is currently running via CGI, one of two conditions is true:
You have chosen well: CGI is appropriate for your application, in which case all web servers with the features you need are interchangeable, because the bottleneck is CGI, not the web server.
You have chosen poorly: CGI is slowing your app down enough that end users notice the speed hit, in which case you need to get off CGI before you start chasing nonstandard web servers, because speeding up the web server won’t solve the primary bottleneck.
(“Nonstandard” meaning that lighttpd is not in the stock CentOS 7 repos. You have to reach out to EPEL to get it.)
I consider Centos as pretty much unusable without software from additional sources. It´s not like all its advantages disappear when using such software, and it´s not like all the required software is included. It´s also not like such software doesn´t work.
There isn´t an ideal solution, either, so why not use Centos for its significant advantages and adjusting it according to what´s needed. So far, it´s working great.
This is not to say that different web servers don’t have advantages even in the CGI case. I run nginx in one extra-small VPS because I don’t have the RAM to run Apache. I couldn’t put enough load on that server to tell any speed difference between Apache and nginx without running it out of CPU or network bandwidth first.
See above, it was merely my impression, not a relevant test. If it works as well and if users get the same impression, it´s fine. If it doesn´t work, I can still use apache.
it can be difficult to run systems using ancient software.
“You keep using that word. I do not think it means what you think it does.”
— Inigo Montoya
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos