[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache
wordpress at santosj.name
Sun Mar 2 18:47:03 GMT 2008
Lloyd Budd wrote:
> On Sun, Mar 2, 2008 at 7:31 AM, Andy Skelton <skeltoac at gmail.com> wrote:
>> On Sun, Mar 2, 2008 at 1:06 AM, Computer Guru <computerguru at neosmart.net> wrote:
>> > I understand the difficulties of making flexible-yet-well-performing
>> > code. I know the tradeoffs between hard-coding stuff and having good
>> > page-load-times. But at the end of the day, /caching is NOT
>> > WordPress's biggest problem/, rather loading too many files at once,
>> > using way more nested loops than it should, and not skipping certain
>> > sections of the code when it can are what's responsible for WP's
>> > "legendary" fear of the /. effect.
>> These are good points. The software could make better performance
>> decisions early in the script. Can you work your ideas into a core
> Failing that maybe Computer Guru you would be interested in mentoring
> a student in that or a related project?
> It sounds similar to a couple of project ideas Matt included last
> year, but that we didn't have a student for:
> * A testing suite that measures performance of various components and
> can be regularly run against new code.
> * Currently WP loads all its code on every page, could a selective
> code loading scheme improve performance in a meaningful way?
> Thank you,
I found that project to be very interesting. I would rather do the
Controller project for the GSOC, but I'll do the Controller project
anyway (which still doesn't mean the core team will accept it).
I've been thinking about both projects, and I have ideas for both. I
probably don't know as much as Computer Guru on the performance topic,
but I know some things from working with improving performance at work.
I think out of the box, WordPress should answer several issues.
1. Caching of queries
2. Support Caching sections of pages and/or whole pages and invalidation
of those caches.
3. Browser Caching Support.
It seems to me, that #3 is only useful for those who visit a WordPress
web site often (CMS usage) and would be very quick since it would only
pull from the disk cache on the visitor's drive. However, it is the more
efficient of the two. Going over it some more, I think it would have to
have support in the query system with some overhead to tell if the page
has been modified. I believe there are some headers which can be sent.
It would help out with CMS projects, which have pages which don't change
For #2, if an API existed that allowed themes to cache certain sections,
pick and choose which parts won't change very often, then a plugin can
take hold of that and cache just those portions based on what the theme
says. Also, there would be an API for plugins to invalidate portions.
Sort of like the widget API, but for caching different sections. There
would be no built in disk caching out of the box, but caching plugins
could be made that don't require having any files in the wp-content
For #1, WordPress would be using the Object Cache anyway, so no big deal
That would be for the caching system and then on to the performance
parts. By using XDebug, you can create a file which tracks the areas
which cause the most performance hits. This might be with using the
PHPUnit Performance test object or with creating a file which reads the
file created by XDebug, parses it, and then outputs the problem areas.
You could do this in a number of ways (PHP ticks for another), but I
think creating a custom solution independent of PHPUnit would probably
be best. This will track parts that need to be optimized.
A third option would be to support Memcache and APC, etc out of the box
and add them to the Object Cache. They would only be enabled if the
extension is installed, so only a small initial amount of overhead to
check every once in a while. If they are enabled then to use them,
instead of placing the caching in the memory. Out of the box, instead of
using a plugin. It shouldn't add that much bloat and will allow plugins
to focus on just disk caching, if it is needed.
Finally, going over the second part's data and optimizing and
refactoring the problem areas will increase initial performance. What
Computer Guru says is true, but you can only offset so much with
optimization before you have to use some form of caching.
For the fourth project item, the only way I can think of is to use
__autoload() function (or probably the SPL version to allow for multiple
autoload functions to be added) or to use a Page Controller instead of
what appears to be a Front Controller, then loading manually what is
needed. You could also do this by having creating a build system that
places all of the wp-includes in a single file and including that file.
You can also have a build system which removes all comments, all
spaces/tabs and tries to remove as many new lines as possible.
If I were to do the project, I wouldn't even mess with the fourth item,
unless the mentor has some other idea that I don't on how to implement
that fourth item. The first three should be enough work on implementing
correctly, as well as optimizing core WordPress functions.
http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers