Optimize PHP framework loading

views:

answers:

Optimize PHP framework loading

Is there a reason all of the modules need to be loaded for every request? Why not allow controllers to specify which modules they require to be loaded, and only load those which are requested?

Amber 2009-08-31 23:29:22

See my response to deceze: the controllers are inside the modules, and the system has to load modules so it can then poll each one asking which modules have content for a given URI.

Josh 2009-08-31 23:37:57

As deceze commented on your reply, that's a rather inefficient way of setting up your framework. :/ At the very least, you might consider allowing a configuration file that specifies what *patterns* a given module might be interested in, so that you can cut down your polling of modules to only ones that at least have a remote chance of being "interested".

Amber 2009-09-01 00:18:54

Why not move step 8 before step 5? Examine the URL first, then load modules based on the results.

Another one:

each module is verified to be valid and free of syntax errors, and then included.

Are you really syntax checking files before including() them? If so, why is this necessary?

deceze 2009-08-31 23:33:30

The syntax checks are one thing I've thought of eliminating, or perhaps caching. They really are syntax checked: they are first read in and eval()ed with a return false; before them.

Josh 2009-08-31 23:36:09

To answer you and Dav, modules must be loaded to process requests because the method of processing a URI is to ask each module, "Got any content for this URI?" and each module responds with the content for that URI and the part of the page the content goes on.

Josh 2009-08-31 23:37:12

That's pretty wasteful indeed (both things). :) You should cache the "got any content" information somewhere, either dynamically or by creating a sort of "profile index" for each module that can be examined without loading the whole thing.

deceze 2009-08-31 23:44:33

@deceze, yes, I agree, I may have to rewrite the framework in such a way that the functionality provided by the modules is cacheable

Josh 2009-09-01 02:36:45

+2 A:

It's generally a bad idea to tie up a dynamic web server thread serving static content. Apache, IIS, Nginx, et. al. already do everything you need to serve up these files. If each static asset is located somewhere within the public docroot and has a unique URL, you shouldn't need to worry about PHP being involved in loading them.

Furthermore, if you can ensure that your cache-related headers (ETag, Last-Modified, etc.) are being generated correctly, and each client should only request each file once. Free caching == win!

rcoder 2009-08-31 23:38:25

You'll also probably see a substantial performance boost by dropping APC (http://us3.php.net/apc/) or another PHP cache tool into your server environment for those URLs which are purely dynamic. It'll save a lot of filesystem traffic loading and parsing all those source files, esp. if you drop the syntax check in your loader.Having the web server handle static content is still usually a bigger win performance-wise, though.

rcoder 2009-08-31 23:41:40

rcoder, I intended to use mod_mem_cache but that messed things up horribly! I posted on serverfault.com about that one.

Josh 2009-08-31 23:41:44

APC is a different kind of cache -- it stores the bytecode that results from parsing PHP source files, rather than their output. Unlike memcached-based page or fragment caches, it doesn't require you to explicitly mark content as cacheable; rather, it just speeds up all your PHP by removing loading and parsing from each request cycle.

rcoder 2009-08-31 23:58:14

rcoder, sorry, forgot to mention I am already using eAccelerator and yes it does provide a nice boost

Josh 2009-09-01 00:02:38

getting mod_cache working solves all my problems. Thanks!

Josh 2009-09-13 14:28:31

ansaurus

tags:

views:

answers:

Optimize PHP framework loading

related questions