Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CGI PHP vs. FastCGI vs. mod_php vs. application server?

19 views
Skip to first unread message

Vincent Delporte

unread,
Jan 3, 2007, 12:58:13 PM1/3/07
to
Hello

I'm interested in hearing reflections by seasoned web app
developpers about the different ways to write PHP apps, and especially
how they compare in terms of performance, whether it's the PHP part or
connections to MySQL.

As far as I know, there are different ways to write a PHP application:
- CGI, ie. the usual way : some PHP code in web pages, and the PHP
interpreter is loaded each time a PHP page is called
- FastCGI : apparently, the interpreter is loaded at boot time; the
application itself might also be compiled and loaded once
- mod_php : same as FastCGI?
- application server : the application is compiled and loaded once;
the application can either have its own web server, or use a web
server as front end, and only handle its own part

Any tips much appreciated, thank you.

NC

unread,
Jan 3, 2007, 2:32:19 PM1/3/07
to
Vincent Delporte wrote:
>
> I'm interested in hearing reflections by seasoned web app
> developpers about the different ways to write PHP apps,
> and especially how they compare in terms of performance,
> whether it's the PHP part or connections to MySQL.

On which HTTP server?

> As far as I know, there are different ways to write a PHP application:
> - CGI, ie. the usual way : some PHP code in web pages, and the
> PHP interpreter is loaded each time a PHP page is called

Yes, but it has not been the usual way for years; most hosting
companies these days do either FastCGI or mod_php.

> - FastCGI : apparently, the interpreter is loaded at boot time; the
> application itself might also be compiled and loaded once

Also, the preferred way of running PHP under Zeus.

> - mod_php : same as FastCGI?

Nope. Different executables. mod_php is a library which Apache
uses to process PHP scripts (there is a similar library for IIS as
well). FastCGI is a standalone executable.

> Any tips much appreciated, thank you.

Check the documentation for your HTTP server. It will likely have
some information about performance improvement with PHP.
Generally speaking, CGI is the worst performer. The choice
between FastCGI and server modules will depend on the HTTP
server you are using.

Cheers,
NC

Vincent Delporte

unread,
Jan 3, 2007, 2:45:06 PM1/3/07
to
On 3 Jan 2007 11:32:19 -0800, "NC" <n...@iname.com> wrote:
>Check the documentation for your HTTP server. It will likely have
>some information about performance improvement with PHP.
>Generally speaking, CGI is the worst performer. The choice
>between FastCGI and server modules will depend on the HTTP
>server you are using.

I'm free to use any server that I want since it'll be hosted on our
premises. Apart from loading the PHP interpreter at boot time, what
else do FastCGI and Apache's mod_php do to increase performance? Do
they compile PHP scripts into bytecode once, do they leave connections
to MySQL open, other things?

Thank you.

Curtis

unread,
Jan 4, 2007, 6:06:56 AM1/4/07
to
On what operating system are you running? I have been very pleased with
Apache 2.0.xx on Win XP pro (although I would prefer to run it on win
2k). The downside is that certain libraries and features aren't ported
to win32 just yet. In a *nix environment, Apache is a very good choice.

I've only used FastCGI with ruby on rails, while I always use mod_php
for PHP. I couldn't provide a fair comparison. Have you googled around?
People have probably performed various tests on performance issues
related to yours.

On Jan 3, 11:45 am, Vincent Delporte <just...@acme.com> wrote:
> On 3 Jan 2007 11:32:19 -0800, "NC" <n...@iname.com> wrote:
>
> >Check the documentation for your HTTP server. It will likely have
> >some information about performance improvement with PHP.
> >Generally speaking, CGI is the worst performer. The choice
> >between FastCGI and server modules will depend on the HTTP

> >server you are using.I'm free to use any server that I want since it'll be hosted on our

Jerry Stuckle

unread,
Jan 4, 2007, 9:06:56 AM1/4/07
to

No, they don't compile PHP into bytecode. The best you're going to do
is to get a package to cache the compiled PHP.

And MySQL connections are generally best NOT being left open. Open
connection still require system resources, even when they are not being
used. And you would need the maximum possible number of connections you
would ever need open all the time.

But I really think you're worrying about performance problems that don't
exist. Just get yourself a decent server, load a good Linux distro and
Apache server on it and go.

Once you've got your site up, see if you have performance problems. If
so, figure out where those problems are and fix them.

Hint: If you do have problems, they won't be in the PHP compiler or
MySQL connection code.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

Vincent Delporte

unread,
Jan 4, 2007, 11:34:08 AM1/4/07
to
On Thu, 04 Jan 2007 09:06:56 -0500, Jerry Stuckle
<jstu...@attglobal.net> wrote:
>But I really think you're worrying about performance problems that don't
>exist. Just get yourself a decent server, load a good Linux distro and
>Apache server on it and go.

OK, but I'd rather know up-front what's available to raise performance
should I have the problem, especially if that involves writing code in
a certain way to use eg. FastCGI, or even using totally different
tools such as writing this as an application server instead of *CGI
like PHP.

So there's no good real-life comparison available to compare those
four solutions to write web applications? For instance, I'd be
intested in hearing about business apps written in PHP in (CGI |
FastCGI | mod_php) vs. Java as an application server. Does it make a
difference? If not, did all those companies choose Java because of the
libraries?

What I'm driving at, is that I'd like to choose a technology based on
real-life data, not just because it's well know (whether it's PHP,
Ruby, Java, etc.)

Thank you.

NC

unread,
Jan 4, 2007, 1:00:53 PM1/4/07
to
Vincent Delporte wrote:
>
> I'd rather know up-front what's available to raise performance
> should I have the problem,

The best thing you can do as a developer is come up with good
data architecture, write efficient SQL and, to borrow a phrase
from Yahoo's Michael Radwin, "use abstraction sparingly".
Most bottlenecks in Web applications come from the database
sever anyway... Beyond that, it's basic programming: efficient
memory use, fast algorithms, etc. Beyond that, it's pure system
administration: use a PHP accelerator, consider enabling
query cache, make sure you have adequate memory on your
system, fine-tune your database server, etc.

With application software already written and deployed, the
only way to "raise performance" (especially in response to
increasing loads) is to change the hardware architecture. First,
you split the front end and the back end (i.e., you have a
dedicated HTTP server and a dedicated database server, each
properly configured for the task). Eventualy, the load may
surpass the capacity of this architecture, and you will have to
further transition to a server cluster (a layer of HTTP servers
and a layer of database servers with load balancing all around).

> So there's no good real-life comparison available to compare those
> four solutions to write web applications? For instance, I'd be
> intested in hearing about business apps written in PHP in (CGI |
> FastCGI | mod_php) vs. Java as an application server.

CGI is patently inferior compared to both FastCGI and mod_php.
On Apache, both FastCGI and mod_php work well. Most ISPs
prefer mod_php, but Yahoo!, for one, likes FastCGI better
(perhaps it has something to do with the fact that most ISPs
run on Linux, whereas Yahoo! prefers FreeBSD). On Zeus,
developers recommend FastCGI.

As to Java, it is not an application server; you can use it with
different application servers (Tomcat, JBOSS, PowerTier,
WebLogic, WebSphere, etc.) Those may have vastly different
performance (and vastly different price tags).

> Does it make a difference?

Here's what Joel Spolsky once had to say on the subject:

the bottom line is that there are three and a half platforms
(C#, Java, PHP, and a half Python) that are all equally
likely to make you successful, an infinity of platforms
where you're pretty much guaranteed to fail spectacularly
when it's too late to change anything (Lisp, ISAPI DLLs
written in C, Perl), and a handful of platforms where The
Jury Is Not In, So Why Take The Risk When Your Job Is On
The Line? (Ruby on Rails)... Python get a half because
it's on the border, about to cross the line from an
"interesting" choice to a "safe" choice.

http://www.joelonsoftware.com/items/2006/09/01.html

> If not, did all those companies choose Java because of the
> libraries?

No, because they had developers well-versed in Java and
a nice round budget for a big-ticket items such as WebLogic/
WebSphere and Oracle. Companies that tried developing
high-load Java applications on a low budget (as in Tomcat +
MySQL) didn't get very far; Friendster, for one, was plagued
with performance problems so pervasive that they had to
switch to PHP. There probably was an alternative, to switch
from MySQL to Oracle and from Tomcat to a commercial
application server, but they may have figured that the licenses
are going to cost more than a complete rewrite of the front
end...

> What I'm driving at, is that I'd like to choose a technology
> based on real-life data,

There is no real-life data. There is only anecdotal evidence.
And you almost never know whether a particular project failed
to meet the requirements because of the poor platform choice
or because developers were inept, or because the planets
were aligned unfavorably... Even people who worked on such
projects often disagree as to the cause of failure; what can
outsiders know for sure?

Cheers,
NC

Vincent Delporte

unread,
Jan 4, 2007, 5:47:10 PM1/4/07
to
On 4 Jan 2007 10:00:53 -0800, "NC" <n...@iname.com> wrote:
>Most bottlenecks in Web applications come from the database
>sever anyway... Beyond that, it's basic programming: efficient
>memory use, fast algorithms, etc. Beyond that, it's pure system
>administration: use a PHP accelerator, consider enabling
>query cache, make sure you have adequate memory on your
>system, fine-tune your database server, etc.

Thanks a lot for the feedback. I'll see if I can write a prototype in
PHP then run it in *CGI and mod_php, then rewrite it as a Python-based
application server, and compare performances.

Cheers,

0 new messages