3

I'm developing a web app for an Apache shared hosting server. I have already written some code in Perl but I recently found out, to my surprise, the shared hosting provider does not provided mod_perl or a way to install it.

I have been a bit worried that running a Perl web app through CGI without mod_perl would make it very slow? Should I switch all of my code to PHP instead, would that be faster?

The reason I chose Perl in the first place is, I'm very familiar with Perl more than PHP. Also I wanted to be able to use my Perl libraries outside the realm of web development.

So if any of you are experienced with Apache web development, can you shed some light as to which direction should I take.

For the sake of this question, lets say the web application will get 500+ hits a day.

Which would be faster PHP or Perl without mod_perl?

Thanks in advance for the help.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Sukhbir S. Dadwal
  • 463
  • 1
  • 8
  • 11

11 Answers11

8

At only 500 hits a day, you could write your code in just about anything and not have to worry about slow downs. 500 hits a day evens out to about 1 page every 3 minutes. Even assuming a non-normal distribution of hits, you shouldn't really worry about this with such small traffic numbers.

Kibbee
  • 65,369
  • 27
  • 142
  • 182
  • 3
    You should worry about it to the extent of not choosing to use anything depending on one of the heftier frameworks such as Catalyst, Moose, or maybe even DateTime. Having so infrequent page hits doesn't mean it's ok the have load times measurable in seconds. – ysth Nov 24 '08 at 02:59
  • @ysth + someday you're going to want to know how to do it the sexy way. I'm guessing there's not much money in 500 hits a day sites! – Chris Huang-Leaver Jan 07 '10 at 15:29
7

PHP would be faster.

However, with only 500 hits per day, using cgi would not be a problem. Not even with 500 hits an hour.

mthurlin
  • 26,247
  • 4
  • 39
  • 46
6

Unless your shared host is running PHP as a CGI application (not mod_php or FastCGI), PHP is almost1 always going to be faster. While Perl, running as a CGI, could probably handle your 500 hits a day, an application/page developed with CGI is going to be sluggish.

CGI works by spawning a new process to run your program for each request. Both mod_php and FastCGI applications mitigate this by spawning a set a number of processes and then using these to run your application. In other words, a new processes isn't being spawned for each request. (This is an oversimplified explanation, please don't use in a CS Term Paper. See mod_php and FastCGI docs for more info)

  1. You could come up with pathological examples where it wouldn't be, but then you'd be the kind of person to come up with pathological examples of things, and no one wants that
brian d foy
  • 129,424
  • 31
  • 207
  • 592
Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • mod_php actually embeds a PHP interpreter in Apache. This makes PHP execute faster, but you really should have an opcode cache installed if you care about speed. – Powerlord Nov 24 '08 at 03:59
  • 2
    You know, if you compare apples to apples, that is, mod_perl to mod_php or perl CGI to PHP CGI, perl is typically somewhat faster. Most certainly not significantly faster, but a little. Try searching for "programming language shootout". – tsee Nov 24 '08 at 20:26
  • I believe it on the apples to apples comparison, but the original poster's question was about shared hosting, and most shared hosts don't support mod_perl, – Alana Storm May 07 '09 at 09:08
  • At the same time, this isn't 1993 anymore, `fork()` really isn't that slow and the volume here does not demand anything outside of CGI. – Jé Queue Mar 02 '12 at 16:56
6

Much depends on your architecture. Modern Perl frameworks aren't well suited for use as CGI (long start-up times). If you use CGI, Catalyst probably is a bad idea. That said, using classical architecture it should be quite manageable.

Leon Timmermans
  • 30,029
  • 2
  • 61
  • 110
5

Speed shouldn't be your concern. Both languages are suitable for web applications.

troelskn
  • 115,121
  • 27
  • 131
  • 155
5

Expanding on what Alan Storm said, you might be able to use Perl with FCGI instead.

FCGI works by having a sort of stand-alone server, a daemon if you like, that connects with your web server via FCGI protocol and delegates/dispatches requests.

This is faster than normal CGI, as this emulates a sort of "servlet" model, the application is persistent, and there is no need for a new initialization on every call like there is with normal CGI.

I have not yet learned how to do this myself, but I believe Catalyst has this option, so its just a matter of learning how to replicate this.

FastCGI/FCGI should be available on drastically more hosts than plain old mod_perl, as FCGI applications are not web-server specific, and some web servers implement PHP via a fcgi utility.

And I've experimented with FCGI webserving a little, and preliminary tests say it can handle at least 500 req/s , far faster than the above concerns of 500/day or 500/hour.

Community
  • 1
  • 1
Kent Fredric
  • 56,416
  • 14
  • 107
  • 150
  • Here is the FastCGI Catalyst docs... http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/Cookbook.pod#FastCGI_Deployment – draegtun Nov 24 '08 at 10:36
5

For the volume of traffic you're looking at, Perl with vanilla CGI shouldn't be an issue, although I would second the earlier recommendations to check out FastCGI as another option which your hosting service may provide.

Or another option would be to look for a different hosting company...

Dave Sherohman
  • 45,363
  • 14
  • 64
  • 102
3

It's possible to hack fastcgi support into a hosting account that doesn't support it. I compiled the fastcgi library with the install prefix set to the same thing as the home directory on the hosting account. Then I synced it up and set up catalyst to use the small cgi-fcgi bridge. It worked well. Nice and fast, because the cgi bridge is just a tiny little executable. The catalyst process persisted in the background just fine.

kingkongrevenge
  • 241
  • 3
  • 14
2

The answer in everyones mind is: who cares. 500 requests per day is nothing.

Just use whats fastest to implement / maintain and move on.

Mischa Kroon
  • 1,772
  • 1
  • 13
  • 19
  • 1
    Every good Software developer should care. I used 500+ as an example, I would love it if my site got 100,000 the point is even if it is 1 hit, it should perform efficiently, unless some ridiculous amount of time is required to make more efficient. – Sukhbir S. Dadwal Nov 24 '08 at 22:36
  • You care if your site gets 500 hits a day and for each one half a second is spent starting your CGI application versus running something preloaded in mod_{php,perl}, because every single user will decide your site is slow and you'll never get to that 100,000. – ijw May 08 '09 at 00:10
  • 1
    @SukhbirS.Dadwal - An excellent developer will do as poster stated, get the job done correctly and within business acceptance and move on. When the requirements change to support a few thousands concurrent sessions, then approach it at that time. Wasting time, effort, resources, and money on solving an CGI speed problem that simply does not exist is simply wasteful. – Jé Queue Mar 02 '12 at 16:59
  • @SukhbirS.Dadwal If your site grows that much what will finally count is the flexibility you'll have to make the site continue evolve to adapt to users' needs. And for that matter the choice of language and framework is more important than speed. – dolmen Aug 31 '12 at 10:04
1

For lighter web frameworks that will work using CGI then have a look at....

AndyG
  • 39,700
  • 8
  • 109
  • 143
draegtun
  • 22,441
  • 5
  • 48
  • 71
0

It depends mostly on how complex your code is and how it's put together; if you run it as CGI, perl will compile your script and modules on each invocation, and will have to reconnect to your database for each request. If your code is complex enough, this may take a few seconds per pageview, which may hamper user experience.

If your codebase and used modules isn't huge though, there should be no problem at all.

You can do a perl -c on your code to get a feel for how long perl startup and your compilation time is.

Gilimanjaro
  • 391
  • 2
  • 8
  • PHP has to recompile your scripts on each invocation if an opcode cache isn't installed. Database connections can be shared, but certain webserver (Apache in prefork mode) deal with this badly. The real speedup of PHP comes from mod_php being embedded in the server process. – Powerlord Nov 25 '08 at 14:55