[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache into WordPress

Eric Marden wp at xentek.net
Sat Mar 1 05:11:42 GMT 2008 

> Thanks for the valuable feedback Eric. I agree, this would be an
> excellent opportunity to start fresh with a new caching system. If  
> anyone
> has any examples of a PHP-based caching system in they feel is  
> better than
> WP Super Cache, I would love to see it.

Take a look at the Zend_Cache in the Zend_Framework


> Regarding things like APC and memcache, correct me if I'm wrong,  
> but I do
> not think the majority of web hosts would be able to support those
> solutions. Very few people would benefit.

Define very few.


This is a matter of perspective. You might not have been exposed to  
anything but shared systems, but many users over the years out grow  
shared hosting and move to more dedicated solutions. I have. And I  
would argue that there are probably plenty of users that self-host  
wordpress on boxes that they have root on --- which is at least gives  
them a shot at APC... memcached probably is a different beast, but  
supporting multiple back-ends would be kind of trivial. File based  
caches have limits. And while they are great when you need them...  
they only scale to a certain point.

But the real heart of the matter is this: just because half of the  
users can only take advantage of one kind of cache back-end, doesn't  
mean we have to 'punish' other users that can take advantage of more  
sophisticated solutions.

On monday, I'll take a closer look at what it might actually take to  
implement other backends, but given that APC and memcached have  
pretty well documented APIs, I feel that supporting them would be  
easier than we might think.

-e


On Feb 29, 2008, at 1:17 AM, Ronald Heft wrote:

> Thanks for the valuable feedback Eric. I agree, this would be an
> excellent opportunity to start fresh with a new caching system. If  
> anyone
> has any examples of a PHP-based caching system in they feel is  
> better than
> WP Super Cache, I would love to see it.

> Regarding things like APC and memcache, correct me if I'm wrong,  
> but I do
> not think the majority of web hosts would be able to support those
> solutions. Very few people would benefit.
>
> Regarding module caching and creating an API for plugins to easily do
> caching, both of those thoughts crossed my mind. Should this idea  
> take off
> amongst the WordPress community, I will certainly look into those  
> options.
>
> Jacob, I'm right there with you on the complex factor. However,  
> complex
> tasks have to undertaken some time, and I feel this is a project  
> that could
> potentially benefit the WordPress community immensely. I admit, I  
> don't know
> everything right now I would need to complete the project, but  
> that's part
> of the Summer of Code. It's a learning experience for the student,  
> and shows
> the true power of the open-source community. If I get stuck, I have  
> the
> backing of my mentor, the WordPress community, and the open source  
> community
> at large. I'm not saying a student should undertake a project without
> knowing a thing about it, but they certainly don't have to know  
> everything.
>
> On Thu, Feb 28, 2008 at 11:46 PM, Eric Marden <wp at xentek.net> wrote:
>
>> I'm all for the idea of including a caching solution into the Core,
>> but I don't think that we should utilize a plugin, that has another
>> plugin as a dependency. I'm not discounting their work -- I use one
>> or the other of those plugins on all of my WP sites.
>>
>> But there is an opportunity here to create a WP wide caching
>> mechanism that could be utilized throughout the code to speed it up.
>> The 3 step cache that WP-Super Cache does is fantastic, but its not
>> complete nor is it an example of the very best caching solution ever
>> -- again this doesn't detract from its usefulness or how great it
>> performs, and is just my opinion.
>>
>> Additional things I'd like to see in a 'core' caching solution:
>>
>> Additional Cache back-ends (apc, memcached, etc)
>> More granular control over what gets cached (header & sidebar are,
>> but posts on page aren't, etc)
>> Ability to use the cache api in my plugins
>> ...etc
>>
>>> How often are you going to edit a past post from 1 week, 1 month,
>> 3 months, 6 months
>>> or one year ago? Probably never.
>>
>> I do it all the time. In fact, I highly recommend going back and
>> reading your old posts... it will make you a better writer, and let
>> you fix obvious mistakes you totally missed before, but you'll also
>> get an interesting look at yourself from an angle you may have never
>> seen before. :)
>>
>> -e
>>
>>
>>
>>
>> On Feb 28, 2008, at 10:20 PM, Jacob Santos wrote:
>>
>>> I was about to disagree, when I remembered the hell of a past
>>> project that involved caching. I still think that the object
>>> caching should always be enabled. However, any solution that is
>>> accepted in to the Core will require test cases. I say this not to
>>> discourage, because really, it isn't up to me to decide.
>>>
>>> I say that only because recently the current disk solution was
>>> stripped out of the object cache and any solution adding it back in
>>> will require support from not only the author of the solution, but
>>> the whole of the WordPress community. If there are test cases, it
>>> will improve the quality of said solution, and hopefully pinpoint
>>> where issues might come up in the future.
>>>
>>> It is very interesting and as an user of WP Super Cache, I can say
>>> that most projects I've used it, it didn't give me any problems.
>>> (There was that one weird problem on GoDaddy that I was never able
>>> to figure out and since the site is high priority, may never find
>>> out). My host seems to accept WP Super Cache with very few problems
>>> (I remember none, but I have a feeling there was once upon a time).
>>>
>>> I think the solution that WP Super Cache offers is a good one. It
>>> answers the question: How often are you going to edit a past post
>>> from 1 week, 1 month, 3 months, 6 months or one year ago? Probably
>>> never. Also, in the best case, if the database ever did go down,
>>> the solution should keep most of the cached pages up for visitors
>>> to see. What I mean, is that in most cases (barring plugins, which
>>> can use the hooks), you could just serve the static HTML pages
>>> instead of making the trip to the database. Changing the theme
>>> wouldn't require "rebuilding," because only the post portion would
>>> be cached, also allowing for comments to be made and updated.
>>>
>>> WordPress 2.5 is increasing performance in some areas. Perhaps, the
>>> root of the problem (another GSOC WordPress project) could be done
>>> first or side by side of this project if a student accepts it.
>>> There is only so much you can do for decreasing overhead and
>>> optimization. At some point APC or friend will have to be used for
>>> performance.
>>>
>>> I do like the idea of caching, so good luck!
>>>
>>>
>>> Ronald Heft wrote:
>>>> Agreed completely. Should this idea be accepted, I would  
>>>> investigate
>>>> potential web host issues. I also agree that caching should
>>>> absolutely be
>>>> disabled by default, because no matter how slick the caching
>>>> solution, there
>>>> are always disadvantages to using caching.
>>>>
>>>> On Thu, Feb 28, 2008 at 9:55 PM, Matt <speedboxer at gmail.com> wrote:
>>>>
>>>>
>>>>> The problem is, said crappy hosts are also likely to have poor
>>>>> configerations that will cause even more problems. Sounds like a
>>>>> good
>>>>> idea, though. However, it should be disabled by default.
>>>>>
>>>>> On Thu, Feb 28, 2008 at 6:52 PM, Ronald Heft
>>>>> <ron at cavemonkey50.com> wrote:
>>>>>
>>>>>> Hello everyone. This is the first of at least few project
>>>>>> proposals from
>>>>>> myself for the upcoming Google Summer of Code 2008. I will be
>>>>>> bouncing
>>>>>>
>>>>> ideas
>>>>>
>>>>>> off the WP-hackers list, so I'm looking for people's opinions of
>>>>>> the
>>>>>> project. Also, if any particular project excites you, feel  
>>>>>> free to
>>>>>>
>>>>> volunteer
>>>>>
>>>>>> as a mentor for the project.
>>>>>>
>>>>>> * Abstract *
>>>>>>
>>>>>> As WordPress accelerates in usage, more and more people are  
>>>>>> become
>>>>>>
>>>>> exposed
>>>>>
>>>>>> to WordPress-generated database error messages on popular social
>>>>>>
>>>>> websites
>>>>>
>>>>>> such as Digg.com. These error messages are by no means the  
>>>>>> fault of
>>>>>> WordPress, just crappy shared hosting services. However,  
>>>>>> people are
>>>>>>
>>>>> seeing
>>>>>
>>>>>> WordPress as the perpetrator of these database crashes.
>>>>>>
>>>>>> Many of these crashes can be avoided by using a caching plugin
>>>>>> such as
>>>>>> WP-cache or WP Super Cache. Unfortunately, not everyone is  
>>>>>> aware of
>>>>>>
>>>>> caching
>>>>>
>>>>>> solutions, or only find about about them when it's too late. My
>>>>>> proposal
>>>>>>
>>>>> is
>>>>>
>>>>>> to integrate a caching solution directly into WordPress, making
>>>>>> regular
>>>>>> WordPress users more aware of caching, while making it more
>>>>>> convenient
>>>>>>
>>>>> to
>>>>>
>>>>>> use.
>>>>>>
>>>>>> * Solution *
>>>>>>
>>>>>> - Talk to existing developers of WP-cache and WP Super Cache
>>>>>> about there
>>>>>> willingness to have their plugins included directly in core.
>>>>>>
>>>>>> - Investigate disadvantages to caching. Does caching require
>>>>>> increased
>>>>>> server requirements compared to a base WordPress install? Does
>>>>>> caching
>>>>>>
>>>>> pose
>>>>>
>>>>>> any security threats?
>>>>>>
>>>>>> - Look over existing caching plugin code and improve upon where
>>>>>> needed.
>>>>>> Ensure adding caching requires no extra steps other than a  
>>>>>> CHMOD of
>>>>>> wp-content.
>>>>>>
>>>>>> - Improve existing caching plugin interface, making it easy to
>>>>>>
>>>>> understand,
>>>>>
>>>>>> and as user friendly as possible.
>>>>>>
>>>>>> - Look over feature requests for caching plugins. Evaluate what
>>>>>> features
>>>>>> would be beneficial to include. See:
>>>>>> http://wordpress.org/tags/wp-super-cache
>>>>>>
>>>>>> - Provide standardized plugin API, so plugins can disable
>>>>>> sections of
>>>>>> caching, eliminating plugin-related caching issues.
>>>>>>
>>>>>> - Investigate other areas of performance increases, optimizing
>>>>>> WordPress
>>>>>> queries and load times where applicable.
>>>>>>
>>>>>> --
>>>>>> Ronald Heft, Jr.
>>>>>> Information Sciences and Technology
>>>>>> Pennsylvania State University
>>>>>>
>>>>>> cavemonkey50.com
>>>>>> 9rules Network
>>>>>> _______________________________________________
>>>>>> wp-hackers mailing list
>>>>>> wp-hackers at lists.automattic.com
>>>>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Matt (speedboxer at gmail.com)
>>>>> http://mattsblog.ca/
>>>>> _______________________________________________
>>>>> wp-hackers mailing list
>>>>> wp-hackers at lists.automattic.com
>>>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Jacob Santos
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
>
>
> -- 
> Ronald Heft, Jr.
> Information Sciences and Technology
> Pennsylvania State University
>
> cavemonkey50.com
> 9rules Network
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list