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.desthuilli...@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. -- http://mail.python.org/mailman/listinfo/python-list
