On Jun 2, 2017, at 5:05 AM, hw <hw at 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. 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/#servers The 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.> Test have shown that > lighttpd apparently is somewhat faster than apache2This 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. Since your app is currently running via CGI, one of two conditions is true: 1. 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. 2. 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.) 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.> 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
Warren Young wrote:> On Jun 2, 2017, at 5:05 AM, hw <hw at 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/#servers > > The 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: > > 1. 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. > > 2. 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos >
On Jun 3, 2017, at 4:13 AM, hw <hw at gc-24.de> wrote:> > I?m using CGI as a simple > means for the users to use the programs...There are less than 10 users.If we?re talking less than one full page hit per second, then it doesn?t much matter what technology you use. You won?t be able to tell from the end user?s perspective. (?One? meaning the page and all its static assets, not the inflated count from all the PNGs, JS files, etc. that may be pulled in by the page proper.)> 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.>>> 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.Not really. With only 10 clients, you likely have 1 or 0 concurrent hits at any one time, which means any web server is probably fast enough. You could probably swap out Apache for HTTP::Server::Simple and still not notice the speed hit.> So what would speak against using lighttpd?If you had to serve thousands of CPS or needed to serve the app in very little RAM, it might be worth switching from Apache to nginx or lighttpd, but since neither applies in your case, you might as well stick with Apache, since that?s the standard web server in CentOS.