Prev: A 'foolproof' way to query inheritance tree? numbers.Real in2.6)
Next: Buy Samsung Corby TXT B3210 Mobile
From: Bruno Desthuilliers on 21 Apr 2010 04:28
Bryan a écrit :
>
> I think I see what you mean

Err...

> -- correct me if I'm wrong:

You are, sorry !-)

> You want to
> keep complex application data structures around between requests.

Nope. I want to keep all my settings parsed, my librairies loaded, all
my connections opened etc. That is, all the time consuming stuff at app
startup - which, with PHP, mostly happens for each and every request.

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

Err... Did you really read what you're answering too ???

Also, I never said this execution model was necessarily bad - just that
it had pros *and* cons.

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

"tends to be a bit unpractical" != "doesn't work".

Many large, sopĥisticated etc applications are written in C. Does that
make C a practical application programming language ?

Now I'm sorry to say that for quite a few "sophisticated" PHP apps I've
seen (and eventually had to work on), the "startup" part - parsing the
include files, configuration, establishing connections etc - took a good
part of the total processing time.
From: Adam Tauno Williams on 21 Apr 2010 05:33
On Wed, 2010-04-21 at 10:28 +0200, Bruno Desthuilliers wrote:
> Bryan a écrit :
> >
> > I think I see what you mean
>
> Err...
>
> > -- correct me if I'm wrong:
>
> You are, sorry !-)
>
> > You want to
> > keep complex application data structures around between requests.
>
> Nope. I want to keep all my settings parsed,

Store them in the session.
> my librairies loaded,

Enable APC

> all my connections opened etc.

If you are talking about RDBMS connections, use persistent connections.

Then you have everything you've asked for.

> Now I'm sorry to say that for quite a few "sophisticated" PHP apps I've
> seen (and eventually had to work on), the "startup" part - parsing the
> include files, configuration, establishing connections etc - took a good
> part of the total processing time.


From: Paul Rubin on 21 Apr 2010 05:40
Bruno Desthuilliers <bruno.42.desthuilliers(a)websiteburo.invalid> writes:
> Nope. I want to keep all my settings parsed, my librairies loaded, all
> my connections opened etc. That is, all the time consuming stuff at
> app startup - which, with PHP, mostly happens for each and every
> request.

I thought we have WSGI for this? Nothing stops a Python app from
working like PHP. PHP has an advantage when you want to run mutually
hostile apps in the same process (relevant if you're running ultra-cheap
shared hosting and you want to put 1000 customers' virtual hosts in the
same mod_php instance), but I don't think you're looking to do that.
From: Chris Rebert on 21 Apr 2010 06:06
On Wed, Apr 21, 2010 at 2:33 AM, Adam Tauno Williams
<awilliam(a)whitemice.org> wrote:
> On Wed, 2010-04-21 at 10:28 +0200, Bruno Desthuilliers wrote:
>> Bryan a écrit :
>> >
>> > I think I see what you mean
>>
>> Err...
>>
>> > -- correct me if I'm wrong:
>>
>> You are, sorry !-)
>>
>> > You want to
>> > keep complex application data structures around between requests.
>>
>> Nope. I want to keep all my settings parsed,
>
> Store them in the session.

I don't think that makes sense. You still have to re-parse the
settings upon starting each new session to store it in the session in
the first place.
Even then, you're suggesting needlessly keeping separate copies of the
settings data for each session, going from O(1) to O(N) in space;
that's rather wasteful.

Cheers,
Chris
--
http://blog.rebertia.com
From: Bryan on 21 Apr 2010 09:15
Bruno Desthuilliers wrote:
> Nope. I want to keep all my settings parsed, my librairies loaded, all
> my connections opened etc. That is, all the time consuming stuff at app
> startup - which, with PHP, mostly happens for each and every request.

O.K. I wasn't clear on your objection. As I said the first time, I
think you've gotten some bad info on PHP. Or maybe you're just behind
the times.

> Many large, sopĥisticated etc applications are written in C. Does that
> make C a practical application programming language ?

It's at least a strong clue.

> Now I'm sorry to say that for quite a few "sophisticated" PHP apps I've
> seen (and eventually had to work on), the "startup" part - parsing the
> include files, configuration, establishing connections etc - took a good
> part of the total processing time.

You didn't say when that was, but PHP caching has come a long way.
Google is your friend.

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