Is fast-cgi a drop-in replacement for mod_php?

Hello group,

If I switched from mod_php to fast-cgi, would I need to make any
changes to my php source?

Also, will something like APC still be useful?

Will my database connections suddenly become persistent?

If I had static data in my script, will it persist when that same
script is called again?

Essentially, my question is: is fast-cgi a drop-in replacement for
mod_php?

Thank you for your time.

E Wilson

Evil Son wrote:
> Hello group,
>
> If I switched from mod_php to fast-cgi, would I need to make any
> changes to my php source?
>

Not much.

> Also, will something like APC still be useful?
>

If you find it useful now, yes.

> Will my database connections suddenly become persistent?
>

Nope.

> If I had static data in my script, will it persist when that same
> script is called again?
>

Nope.

> Essentially, my question is: is fast-cgi a drop-in replacement for
> mod_php?
>

Pretty much. But nothing will give you the behavior you're looking for.
The web is by nature transactional, and all languages act the same way
- scripts are initialized when you call them and do not carry over
values or connections from previous executions.

> Thank you for your time.
>
> E Wilson
>


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

> Evil Son:
> > Essentially, my question is: is fast-cgi a drop-in replacement for
> > mod_php?

Jerry Stuckle:
> Pretty much. But nothing will give you the behavior you're looking for.
> The web is by nature transactional, and all languages act the same way
> - scripts are initialized when you call them and do not carry over
> values or connections from previous executions.

Quite the contrary, I was hoping it behaved much like mod_php for code
compatibility and simplicity.

I must admit though that this behaviour is surprising since part of
the reason for fastcgi (as I understood it anyway) was to maintain
state/resources across requests - e.g. an open database connection.
It seems that PHP in fastcgi mode doesn't ... and I'm quite happy with
that as it avoids a whole class of bugs.

Thanks!

..oO(Evil Son)

>I must admit though that this behaviour is surprising since part of
>the reason for fastcgi (as I understood it anyway) was to maintain
>state/resources across requests - e.g. an open database connection.

Not exactly. The main problem with "normal" CGI is that on every single
request the script interpreter or external program has to be invoked
over and over again, because after handling the request the program will
be terminated. This not only slows down the execution, it also wastes
memory if multiple instances of the interpreter are loaded at the same
time.

FastCGI helps to overcome these performance issues by loading the
interpreter only once if possible and keeping it in memory. But this
only affects the interpreter itself, it doesn't magically turn PHP into
a real application server.

>It seems that PHP in fastcgi mode doesn't ... and I'm quite happy with
>that as it avoids a whole class of bugs.

There are some minor differences between the server module and a
(Fast)CGI version (some features/functions are only available in the
module), but most things work exactly the same.

Micha

Evil Son wrote:
>> Evil Son:
>>> Essentially, my question is: is fast-cgi a drop-in replacement for
>>> mod_php?
>
> Jerry Stuckle:
>> Pretty much. But nothing will give you the behavior you're looking for.
>> The web is by nature transactional, and all languages act the same way
>> - scripts are initialized when you call them and do not carry over
>> values or connections from previous executions.
>
> Quite the contrary, I was hoping it behaved much like mod_php for code
> compatibility and simplicity.
>
> I must admit though that this behaviour is surprising since part of
> the reason for fastcgi (as I understood it anyway) was to maintain
> state/resources across requests - e.g. an open database connection.
> It seems that PHP in fastcgi mode doesn't ... and I'm quite happy with
> that as it avoids a whole class of bugs.
>
> Thanks!
>
>

Not at all. Fastcgi just keeps the module in memory so it doesn't have
to be loaded and initialized every time.

Think about it - what happens if the last time the particular script was
called it was a different user? You wouldn't want someone else to get
access to your bank account!

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

> Evil Son wrote
> > I must admit though that this behaviour is surprising since part of
> > the reason for fastcgi (as I understood it anyway) was to maintain
> > state/resources across requests - e.g. an open database connection.
> > It seems that PHP in fastcgi mode doesn't ... and I'm quite happy with
> > that as it avoids a whole class of bugs.
>
> > Thanks!

Jerry Stuckle:
> Not at all. Fastcgi just keeps the module in memory so it doesn't have
> to be loaded and initialized every time.
>
> Think about it - what happens if the last time the particular script was
> called it was a different user? You wouldn't want someone else to get
> access to your bank account!

:-)
Here is what caused me to ask how things worked for PHP:
http://www.fastcgi.com/devkit/doc/fa...intro.htm#8485

Thanks again.

Evil Son wrote:
>> Evil Son wrote
>>> I must admit though that this behaviour is surprising since part of
>>> the reason for fastcgi (as I understood it anyway) was to maintain
>>> state/resources across requests - e.g. an open database connection.
>>> It seems that PHP in fastcgi mode doesn't ... and I'm quite happy with
>>> that as it avoids a whole class of bugs.
>>> Thanks!
>
> Jerry Stuckle:
>> Not at all. Fastcgi just keeps the module in memory so it doesn't have
>> to be loaded and initialized every time.
>>
>> Think about it - what happens if the last time the particular script was
>> called it was a different user? You wouldn't want someone else to get
>> access to your bank account!
>
> :-)
> Here is what caused me to ask how things worked for PHP:
> http://www.fastcgi.com/devkit/doc/fa...intro.htm#8485
>
> Thanks again.
>

As you can see from the responses, that page is not entirely correct.

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

..oO(Evil Son)

>Here is what caused me to ask how things worked for PHP:
>http://www.fastcgi.com/devkit/doc/fa...intro.htm#8485

If you think of the PHP interpreter itself being the FastCGI application
and not your own script, then things might become more clear. It's just
the interpreter that is kept in memory and running as described on the
page, but your own scripts are still re-evaluated on every request.

Micha