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