Prev: A 'foolproof' way to query inheritance tree? numbers.Real in2.6)
Next: Buy Samsung Corby TXT B3210 Mobile
From: Adam Tauno Williams on 20 Apr 2010 08:40
On Mon, 2010-04-19 at 15:15 +0200, Bruno Desthuilliers wrote:
> Gilles Ganault a écrit :
> > On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
> > <bruno.42.desthuilliers(a)websiteburo.invalid> wrote:
> >> The PHP execution model (mostly based on CGI FWIW) tends to be a bit
> >> unpractical for non-trivial applications since you have to rebuild the
> >> whole world for each and any incoming request, while with a long-running
> >> process, you load all your libs, parse your config etc only once.

There are numerous ways to efficiently retains state between page views
[session id + memcache or even just shared memory].

> > Apart from the ease of having the application run at all times, I'd be
> > curious to read about an application that was written in PHP and then
> > a long-running process and see if performance improved.
> I'm not sure there's a way to do such a thing in PHP,

There isn't. [Speaking as an ~15 year administrator and developer].
Also PHP's memory management is *B*A*D*, so please don't try to create
long running processes in PHP.

But if you have intensive processing to do your web front end should
signal a backend to do the 'real' work; keeping your front end thin and
svelt. There are numerous ways to accomplish that.

> Now there are a couple Symfony / Django benchmarks around (Symfony being
> probably the closest thing to Django in the PHP world). They are just as
> reliable as most benchmarks (that is, at best a rough indicator once you
> understand what's effectively being measured), but it seems that they
> confirm the empirical evidence that PHP is not well suited for such
> "heavy" OO frameworks.
> > Regardless, Python has an easier syntax, so AFAIC, that's already a
> > good enough reason to use this to write web apps.
> Indeed !-)


From: Bruno Desthuilliers on 20 Apr 2010 11:00
Bryan a �crit :
> Bruno Desthuilliers wrote:
>> Gilles Ganault a �crit :
>>> Apart from the ease of having the application run at all times, I'd be
>>> curious to read about an application that was written in PHP and then
>>> a long-running process and see if performance improved.
>> I'm not sure there's a way to do such a thing in PHP, at least in a way
>> that wouldn't make the whole benchmark totally meaningless.
>
> I think you guys got some incorrect info about PHP. A variety of
> execution options are available, such as FastCGI and in-server
> modules.

mod_php, yes, but that doesn't change anything to the fact that it has
to rebuild the whole world on each and every request. Not the same as a
true long-running process.

So, yes, you COULD write a cli PHP app, daemonize it, and add a mod_php
/ FastCGI / whatever request handler to interface the cli app with the
web server, but that would be kinda pointless, wouldn't it ? FWIW,
that's what I was thinking about when asserting it would "make the whole
benchmark totally meaningless".

> PHP frameworks generally allow and encourage application code
> to be independent of the underlying plumbing.

This is debatable at best. PHP code (except cli PHP code of course) is
written without any care for persistent global state, concurrency
issues, race conditions etc - because it's written with the idea that
the code serving a request will be runned in total isolation. CGI
heritage here, obviously. And please note I'm not criticizing this
design- just pointing one of it's consequences.

> Many large,
> sophisticated, high-volume web apps are in PHP.

Did anyone pretend otherwise ?

> We like Python 'round here, but PHP, Ruby, Perl, Java, and others are
> viable languages for web apps.

Did anyone pretend otherwise ?

> Each has its distinguishing features --
> how efficiently a web app gets invoked is not among them. It's not a
> language issue.

Well, when it comes to PHP, yes, it's somehow built in the language -
PHP was designed from the ground to be a server page language, and to
have each request served in total isolation (cf above).

> What was the theory here? Did we think the PHP
> community too stupid to understand FastCGI?

Bryan, I'm afraid you're reacting to something that was nowhere written
in this thread.

From: Bruno Desthuilliers on 20 Apr 2010 11:05
Adam Tauno Williams a écrit :
> On Mon, 2010-04-19 at 15:15 +0200, Bruno Desthuilliers wrote:
>> Gilles Ganault a écrit :
>>> On Thu, 15 Apr 2010 12:41:56 +0200, Bruno Desthuilliers
>>> <bruno.42.desthuilliers(a)websiteburo.invalid> wrote:
>>>> The PHP execution model (mostly based on CGI FWIW) tends to be a bit
>>>> unpractical for non-trivial applications since you have to rebuild the
>>>> whole world for each and any incoming request, while with a long-running
>>>> process, you load all your libs, parse your config etc only once.
>
> There are numerous ways to efficiently retains state between page views
> [session id + memcache or even just shared memory].

Never played with shared memory in PHP. Sessions will at best retains
"state" (data), and it's not a free lunch neither (you'll still have to
reload that state one way or another). And you'll still have to parse
included .php files on each and every request.

>
>>> Apart from the ease of having the application run at all times, I'd be
>>> curious to read about an application that was written in PHP and then
>>> a long-running process and see if performance improved.
>> I'm not sure there's a way to do such a thing in PHP,
>
> There isn't. [Speaking as an ~15 year administrator and developer].
> Also PHP's memory management is *B*A*D*, so please don't try to create
> long running processes in PHP.

Wasn't designed for such a thing anyway !-)

> But if you have intensive processing to do your web front end should
> signal a backend to do the 'real' work; keeping your front end thin and
> svelt. There are numerous ways to accomplish that.


For which definition of "intensive processing" ? Building a web page
with Drupal when you have a dozen modules hooked here and there can
already imply some processing...
From: Bryan on 20 Apr 2010 16:54
Bruno wrote:
> Bryan a écrit :
> > I think you guys got some incorrect info about PHP. A variety of
> > execution options are available, such as FastCGI and in-server
> > modules.
>
> mod_php, yes, but that doesn't change anything to the fact that it has
> to rebuild the whole world on each and every request. Not the same as a
> true long-running process.

> So, yes, you COULD write a cli PHP app, daemonize it, and add a mod_php
> / FastCGI / whatever request handler to interface the cli app with the
> web server, but that would be kinda pointless, wouldn't it ?

I think I see what you mean -- correct me if I'm wrong: You want to
keep complex application data structures around between requests. That
sounds appealing in terms of efficiency, but it's bad for scalability
and robustness.

> > PHP frameworks generally allow and encourage application code
> > to be independent of the underlying plumbing.
>
> This is debatable at best. PHP code (except cli PHP code of course) is
> written without any care for persistent global state, concurrency
> issues, race conditions etc - because it's written with the idea that
> the code serving a request will be runned in total isolation. CGI
> heritage here, obviously.

No, that's good web-app structure, regardless of language and server
interface. If we keep persistent global state in a shared database
rather than program variables, then we can run the app in multiple
processes and, if our service hits the big time, multiple hosts.


> And please note I'm not criticizing this
> design- just pointing one of it's consequences.
>
> > Many large,
> > sophisticated, high-volume web apps are in PHP.
>
> Did anyone pretend otherwise ?

How about this howler: "The PHP execution model (mostly based on CGI
FWIW) tends to be a bit unpractical for non-trivial applications".


--
--Bryan
From: Bryan on 22 Apr 2010 08:48
Emile van Sebille wrote:
> You're missing the point -- set-up and tear-down overhead is involved
> for both python and php cgi based web serving, and Bruno I'm sure would
> concur that python in this suffers similarly.

Well I wrote, "Each has its distinguishing features -- how efficiently
a web app gets invoked is not among them. It's not a language issue."
Bruno disagreed when it comes to PHP. But obviously Bruno and I don't
communicate all that well.

--
--Bryan
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: A 'foolproof' way to query inheritance tree? numbers.Real in2.6)
Next: Buy Samsung Corby TXT B3210 Mobile