Prev: A 'foolproof' way to query inheritance tree? numbers.Real in2.6)
Next: Buy Samsung Corby TXT B3210 Mobile
From: Bruno Desthuilliers on 15 Apr 2010 06:41
Gilles Ganault a �crit :
> So it looks like, unlike PHP, the prefered solution in Python is to
> build a complete application as a long-running process, and either use
> its embedded web server or configure a stand-alone web server to act
> as reverse proxy using either FastCGI or WSGI to connect the two.

Yeps. You'll find the same pattern with most general purpose programming
languages, and specially OO ones.

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.

Also, gateways like FastCGI or WSGI avoids being tied to a specific web
server.
From: Gilles Ganault on 15 Apr 2010 12:19
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.

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.

Regardless, Python has an easier syntax, so AFAIC, that's already a
good enough reason to use this to write web apps.
From: Adam Tauno Williams on 20 Apr 2010 13:36
On Tue, 2010-04-20 at 17:05 +0200, Bruno Desthuilliers wrote:
> 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).

I'd prefer the term "access" over "reload".

> And you'll still have to parse included .php files on each and every request.

False. Production sites [all?] use interpreter caches that maintain
'compiled' pages in shared memory. This works *very* well.

> >>> 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 !-)

Exactly; that never stops people from trying.

> > 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...

Again, the compilation of the modules is cached. The amount of
processing required for 'import...' declines to near zero.

From: Bryan on 20 Apr 2010 07:09
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. PHP frameworks generally allow and encourage application code
to be independent of the underlying plumbing. Many large,
sophisticated, high-volume web apps are in PHP.

We like Python 'round here, but PHP, Ruby, Perl, Java, and others are
viable languages for web apps. Each has its distinguishing features --
how efficiently a web app gets invoked is not among them. It's not a
language issue. What was the theory here? Did we think the PHP
community too stupid to understand FastCGI?


--
--Bryan Olson
From: Bruno Desthuilliers on 19 Apr 2010 09:15
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.
>
> 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. And trying
to compare a PHP app with a similar non-PHP would also be (mostly)
meaningless.

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 !-)
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