On Feb 9, 5:01 am, "Nimrod A. Abing" <[email protected]> wrote: > On Mon, Feb 9, 2009 at 8:26 AM, Graham Dumpleton > > <[email protected]> wrote: > > > In response to some claims about mod_wsgi embedded mode being worse > > than daemon mode and with it being said to be no better than > > mod_python, I have updated: > > > http://code.google.com/p/modwsgi/wiki/PerformanceEstimates > > > with a few comments about how it is important not to use default MPM > > settings for mod_wsgi and mod_python if using embedded mode. > > > I intend to blog about this some more, but first have a question which > > someone knowledgeable about PHP can perhaps help me with. > > > In PHP, it preloads all its extension modules in the Apache parent > > process. That is, they have been loaded even before Apache forks off > > the child processes which handle requests. As a result, creation of > > new child processes capable of handling PHP requests is very quick > > with neglible overhead. > > > In contrast, for mod_python/mod_wsgi, only the Python interpreter is > > initialised in the Apache parent process. Any extension modules are > > only loaded in the child process when an application runs in response > > to handling a request. > > > This lazy loading with Python means that there can be significant > > delayed startup cost which occurs only in the child processes and > > which is incurred in every child process created. Part of the comments > > in that updated wiki page highlight how the default MPM settings in > > Apache are actually probably really bad in respect of this, > > specifically where fat Python web applications are use. > > > As to my question, what I want to know is if for PHP if all extension > > modules are always preloaded and thus user code has no ability to load > > any additional modules itself. In other words, are PHP users at the > > mercy of the administrator as far as what extension modules are > > available, and if they want something else they are stuffed? Or, can a > > user somehow install an extension module somewhere himself and say > > that it should be loaded by his application, much like Python's import > > system works? > > When it comes to C extensions, PHP does not have anything that will > allow you to dynamically load extensions at runtime. So yes, > essentially you are stuck with whatever PHP configuration that your > virtual hosting provides if you are using Apache SAPI. If you are > using CGI it might be possible via wrapper scripts to run PHP with a > different php.ini and load your own C-extensions. However a lot of > virtual hosting providers do not allow this for security reasons. > There is also the fact that you must compile your extensions against > *the same* libraries that your server's PHP and Apache are compiled > against. > > I have to agree that the default MPM settings provided with Apache out > of the box can hurt mod_wsgi performance.Comparing an out of the box > install of Apache+mod_wsgi against PHP on a virtual hosting provider > is not a fair comparison. Virtual hosting providers already have > pre-tuned Apache configurations that are geared towards PHP > application performance. By tweaking our server's MPM configuration I > was able to achieve equal if not better performance with mod_wsgi. > Although YMMV as different applications will have different needs.
if the c extension is not in the list of the bottom of http://87.98.218.86/phpinfo.php you are screwed as a user. But that does not mean that the list can not be huge. As i understand php does allot of sharing :-) Not to mention it sucks even more at multi threading then python does :P --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
