On Jun 3, 2017, at 4:13 AM, hw <h...@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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Reply via email to