MySQL MEMORY worth using for an object cache?

[Andy Skelton]

On 4/17/07, Computer Guru <computerguru@...> wrote:
> You know, with the importance of Caching, I'm surprised the MySQL team
> hasn't developed a pure-caching extension for MySQL itself.....

MySQL has a built-in query cache that can be a tremendous help when
the same queries are repeated again and again. Database servers can
have many gigabytes of RAM dedicated to this cache.

Much of what WordPress caches is exactly what it gets from the wpdb
object but the best things to cache are the most expensive--those that
take the most time to generate--and the most-often used.

Now I'm really glad you brought MySQL into this because it reminded me
that MySQL has a database engine that might work very well as a
baseline, persistent object cache. I'm almost certain it would be
faster than core's file-based cache if it were well-written. I'm
talking about the MEMORY (HEAP) engine, which may be available in
enough places to make it core-worthy. (If this is a horrible idea I
hope Deaton chimes in right away.)

If somebody wanted to bang out a client I'd really like to lend an
eyeball or two, maybe even a hand, to see if it would be an
improvement.

Andy
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

As far as I know, there isn't anything particularly wrong with using
MySQL's query caching afaik. It would almost certainly be faster than
file based caching, however there are advantages and disadvantages to
each.

The advantage of using MySQL is indeed using RAM, which is many
magnitudes faster than disk based files. The disadvantage, however, is
that you still have MySQL connection overhead, a limited number of
connections to the MySQL server, etc. On a server expecting burst
traffic or just flat out heavy traffic, its worthwhile to use the
diskbased cache instead to relieve some of the stress from the MySQL
server.

It is because of this that I'd choose APC or memcached as a persistent
object cache backend. Probably APC because there is no daemon there
either, it can be stored straight to RAM and retrieved straight from
RAM.

Might want to get someone else's opinion on this one though.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Andy Skelton]

On 4/17/07, Robert Deaton <false.hopes@...> wrote:
> The advantage of using MySQL is indeed using RAM, which is many
> magnitudes faster than disk based files. The disadvantage, however, is
> that you still have MySQL connection overhead, a limited number of
> connections to the MySQL server, etc. On a server expecting burst
> traffic or just flat out heavy traffic, its worthwhile to use the
> diskbased cache instead to relieve some of the stress from the MySQL
> server.

There is no reason that this should cause additional connections.
Memory tables can live in the same database as other types.

> It is because of this that I'd choose APC or memcached as a persistent
> object cache backend. Probably APC because there is no daemon there
> either, it can be stored straight to RAM and retrieved straight from
> RAM.

I have no personal experience with APC. For any setup that needs to
scale beyond a single web server I would choose memcached. However,
the idea was to replace the disk-based cache with something that (a)
improves performance under load for the majority of installs
(shared/VPS) and (b) can be enabled by default.

Here is the horse's mouth:
http://dev.mysql.com/doc/refman/4.1/en/memory-storage-engine.html

And some highlights from the above:
MEMORY tables use a fixed-length row storage format.
MEMORY tables cannot contain BLOB or TEXT columns.
MEMORY tables are never converted to disk tables. To ensure that you
don't accidentally do anything foolish, you can set the
max_heap_table_size system variable to impose a maximum size on MEMORY
tables. For individual tables, you can also specify a MAX_ROWS table
option in the CREATE TABLE statement.

Even if it were limited to 10-20 rows at 50-100k per row, that
megabyte of RAM might be very useful for caching the ten or twenty
pages that get the most views. Typically that's the front page and a
few posts as rendered sans cookies.

Andy
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Paul Menard-2]

On Apr 17, 2007, at 6:24 AM, Robert Deaton wrote:
> It is because of this that I'd choose APC or memcached as a persistent
> object cache backend. Probably APC because there is no daemon there
> either, it can be stored straight to RAM and retrieved straight from
> RAM.

Robert, just wondering about your choice of words in the above. The  
way it's written you are almost stating APC is an alternate to using  
MySQL caching. In my development experience for high traffic sites  
these are two different technologies that can really compliment each  
other. My understanding of APC is it just caches the pre-compiled php  
object code for Apache. Which is better than having repeated requests  
for the same PHP page causing recompile from source every time. The  
actual WordPress page content is not stored as part of the object.  
This is just the PHP object code that still needs to be executed to  
build the output.

Paul
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[David Chait]

And just to chime in, I agree that for high-volume sites, with complete
dedi server control, you can make great use of APC/memcached on the
'front end', BUT that can be tuned/balanced with effective use of the
MySQL query cache -- ESPECIALLY if you have enough $$ to have a separate
MySQL box (or four).  Then, in some cases, I can see the query cache
being a big impact.  It depends on the ram in the two boxes, what's
allocated to what.  Pulling over the lan out of ram should usually be
faster than storing to disk, so if you are thrashing memcached ram
storage for query/object caching on the front-end, you might be better
off letting MySQL do it.  At least, that's my understanding -- I've
never had a dedi box to try out on! ;)

Some quick notes for other readers.

1) memcached is a general persistant caching mechanism, that can store
any serialized data in local ram for quick retrieval.  It's a great
drop-in replacement for the default to-disk caching of the wp object
cache.  there are a few other caching daemons (xcache for one).  
memcached actually is designed to allow the memory storage be remoted
(to another box) which basically gives you ram-over-lan-based caching --
can be powerful if you want a big-ram box in back, with a lot of fast
apache (or lighttpd, thttpd, etc.) servers in front, and mysql on the
side. ;)

2) APC is a php 'opcode cache'.  it makes your PHP 'dynamic' code load
and run quickly.  you need to tune its memory use properly from what I
understand.  and, I've also read about people making APC network
distributed too, though I'm not sure in what cases you'd win remoting an
opcode cache's results vs regenerating locally.  There are other popular
opcode caches, including I though Zend had one themselves (but I think
Zend's is $$$, the others are usually free...).

So, two different parts of the equation, plus mysql query caching, gives
you a 'hierarchy of caching mechanisms'.  Lots of places to tune.

However, just as a reminder, these solutions are only for dedi platforms
-- they have zero impact on shared servers (well, you have no control,
the host could use them if desired...).  And in some cases, some of them
only make big impacts when you are talking multiple boxes.

Back to the original question. ;)  I wouldn't think MySQL object cache
would be all that useful as a generalized cache, better to use
memcached.  Again, zero experience, just from reading.  Then again, if
you have a beefy-but-underused MySQL box, and a heavily-overused
webserver, then yeah, I could see shifting data over to the db box being
useful.  But at that point, why not just let the mysql query cache do
its job, and get the object cache out of the way?

-d

Robert Deaton wrote:

> As far as I know, there isn't anything particularly wrong with using
> MySQL's query caching afaik. It would almost certainly be faster than
> file based caching, however there are advantages and disadvantages to
> each.
>
> The advantage of using MySQL is indeed using RAM, which is many
> magnitudes faster than disk based files. The disadvantage, however, is
> that you still have MySQL connection overhead, a limited number of
> connections to the MySQL server, etc. On a server expecting burst
> traffic or just flat out heavy traffic, its worthwhile to use the
> diskbased cache instead to relieve some of the stress from the MySQL
> server.
>
> It is because of this that I'd choose APC or memcached as a persistent
> object cache backend. Probably APC because there is no daemon there
> either, it can be stored straight to RAM and retrieved straight from
> RAM.
>
> Might want to get someone else's opinion on this one though.
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

On 4/17/07, Andy Skelton <skeltoac@...> wrote:

> On 4/17/07, Robert Deaton <false.hopes@...> wrote:
> > The advantage of using MySQL is indeed using RAM, which is many
> > magnitudes faster than disk based files. The disadvantage, however, is
> > that you still have MySQL connection overhead, a limited number of
> > connections to the MySQL server, etc. On a server expecting burst
> > traffic or just flat out heavy traffic, its worthwhile to use the
> > diskbased cache instead to relieve some of the stress from the MySQL
> > server.
>
> There is no reason that this should cause additional connections.
> Memory tables can live in the same database as other types.

Sorry, I should have worded it better. What I was trying to say is
that, when you're trying to squeeze performance out, the overhead of
connections to the MySQL server is still there when using these sorts
of tables. For a site that's under heavy slashdot or digg traffic, for
example, its not uncommon to hit the mysql connection limit with your
scripts, whereas a diskbased or other non-MySQL method for persistent
object caching does not suffer this limitation.

> > It is because of this that I'd choose APC or memcached as a persistent
> > object cache backend. Probably APC because there is no daemon there
> > either, it can be stored straight to RAM and retrieved straight from
> > RAM.
>
> I have no personal experience with APC. For any setup that needs to
> scale beyond a single web server I would choose memcached. However,
> the idea was to replace the disk-based cache with something that (a)
> improves performance under load for the majority of installs
> (shared/VPS) and (b) can be enabled by default.
>
> Here is the horse's mouth:
> http://dev.mysql.com/doc/refman/4.1/en/memory-storage-engine.html
>
> And some highlights from the above:
> MEMORY tables use a fixed-length row storage format.

Yes, and for the size of the objects we'd like to cache, this may
hurt. char columns or binary columns can only have a length of up to
255. I guess theoretically we could do splitting in PHP and concat
them back out.

> MEMORY tables cannot contain BLOB or TEXT columns.

I believe that's a given due to the fixed-length row storage :)

> MEMORY tables are never converted to disk tables. To ensure that you
> don't accidentally do anything foolish, you can set the
> max_heap_table_size system variable to impose a maximum size on MEMORY
> tables. For individual tables, you can also specify a MAX_ROWS table
> option in the CREATE TABLE statement.


> Even if it were limited to 10-20 rows at 50-100k per row, that
> megabyte of RAM might be very useful for caching the ten or twenty
> pages that get the most views. Typically that's the front page and a
> few posts as rendered sans cookies.

Ah, caching whole pages? I didn't get that impression from your
original mail. Interesting thought.


--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

On 4/17/07, Paul Menard <codehooligans@...> wrote:

>
> On Apr 17, 2007, at 6:24 AM, Robert Deaton wrote:
> > It is because of this that I'd choose APC or memcached as a persistent
> > object cache backend. Probably APC because there is no daemon there
> > either, it can be stored straight to RAM and retrieved straight from
> > RAM.
>
> Robert, just wondering about your choice of words in the above. The
> way it's written you are almost stating APC is an alternate to using
> MySQL caching. In my development experience for high traffic sites
> these are two different technologies that can really compliment each
> other. My understanding of APC is it just caches the pre-compiled php
> object code for Apache. Which is better than having repeated requests
> for the same PHP page causing recompile from source every time. The
> actual WordPress page content is not stored as part of the object.
> This is just the PHP object code that still needs to be executed to
> build the output.

APC also has shared memory functions which can easily be used for an
object caching backend. Sorry to confuse, I just assumed that people
following the thread would know that.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

Okay, here's a few little tidbits from my experiences making WP scale
while keeping it on a single server. These won't be useful for shared
hosting, but the tidbits of information here might give you some
insight into why I say what I say. :)

1). APC alone will do wonders. I know this is no good for shared hosts
but if they got the hint, it'd be absolutely wonderful. As times goes
on, more and more shared hosts are and will be adpoting APC,
especially around the PHP6 launch which is supposed to have APC or an
equivalent object caching backend built in.

2). Tweaking MySQL's internal query cache options and size can do
wonders, however on a single box that expects to take a beating its
not enough. Something is going to be needed on the frontend to help
keep some of the load off the MySQL server for queries.

3). Don't bother using memcached on a single box. The APC backend for
WP's object cache will outperform it anyday, you don't need a seperate
daemon running to handle the requests.

4). Full page to disk caching does more harm than good on a server
that is expecting a beating, especially one like digg or slashdot. The
reason for this is that often times so many comments are posted that
the server is constantly having to regenerate these pages and write
them back to disk. Under heavy load, any moderately powered server
won't usually have a hard time keeping up as far as CPU time goes, its
file IO time, especially from disk (this is why APC helps immensely,
WordPress loads a metric asston of files from disk otherwise). Using
APC, the cost in CPU time for having to regenerate the pages easily
outweighs the cost of having to pull the PHP source from disk. It
isn't the recompilation that hurts WordPress the most, its disk IO.

5). lighttpd > Apache. The end.


Now that those are out of the way, what can we do to help the average
user on a shared host not kill the server?

I am not opposed to checking for the existance of sysvsem, sysvshm,
shmop, and APC, and attempting to use those as RAM storage. Writing
backends for each of them is fairly straightforward, and when loading
the object cache we could simply check for the existence of them and
automatically load the first one that matches what we need. A constant
in wp-config.php could be used to stop WordPress from automatically
loading one of these backends.

MySQL MEMORY for an object cache is also an option, but a potentially
risky one, especially for things like posts as they differ largely in
size, and we do have the fixed row limitation. I guess we could
implement it as an object cache and see how it performs, and try to
find a good balance between a size for all user's posts and a size
that doesn't eat too much unnecessary memory. I'm not sure, due to the
nature of only being able to store 255 chars in column, if using it to
do full page caches ala WP-Cache is a good option.

I believe there's some smaller optimizations that still may help. I
personally believe throwing all the files together into one giant
include would likely help. I also have a feeling that what Andy and I
have been discussing recently as far as on-demand function loading may
also help.

Our MySQL queries can still likely be optimized a bit, and this is key.

WP-Cache could use a rewrite from the ground up as well, imho. I wish
I had more time to take this project under, but perhaps I will anyways
in the coming weeks, or once summer starts.

There's a few other things but I think I've fueled this fire plenty
for the moment.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Computer Guru]

I do exactly that on my dedicated server (Window Server 2003, IIS 6, Tons of ISAPI Extensions) but the only difference being that I'm running IIS instead of Lighttpd, and eAccelerator instead of APC.

I know APC is the "standard," but it breaks many scripts (on my site, it's gallery2) so eAccelerator does the trick, and I find it to be just as fast and a bit lighter too.

In the past week, my site was (honored to be) on Slashdot's main page twice in 4 days, with the latter being a very highly popular article that's above normal for even the Slashdot effect (still, even now 3 days later). I finally had a chance to test out some of my tuning, and I'm really proud to say that WP survived without a single second of downtime :)

I'm not using WP-Cache or anything of that sort, and my blog issues 36-44 queries per requested page (thanks to WP's badly designed db layer that makes all these plugins issue separate queries for their stuff).

Just want to add a couple more things:
If you're using mod_gzip (or an IIS equivalent), make SURE it auto-disables under heavy load.
I'm using a proprietary IIS ISAPI extension that turns off gzip completely if CPU load hits 90% in order to free up cpu cycles for serving requests and dealing with the load.

On Windows, defragmenting actually makes a difference with regards to the amount of disk access needed to pull a file. I recommend PerfectDisk 8.

Switch your WP tables to Innodb. WP (by default) doesn't require any MyISAM-specific features. Innodb is far faster for most SQL usages (the exception being constant real-time logging of server requests, etc)

If you're using ISAPI PHP extensions, switch to FastCGI. If you're using CGI, that goes without saying. The first is because of reliability under load (PHP's ISAPI extensions are pure crap), the second is just pure performance. How-to: http://neosmart.net/blog/2007/opensource-on-windows-and-iis/

I benched lighttpd vs. IIS 6, and basically inconclusive results for issuing dynamic files. Once I expand to two servers however, I'll probably run lighttpd for serving downloads and images - big difference there!

I also have WP's inbuilt object caching enabled....

Thanks for your excellent tips, Robert. I think that about covers everything I've seen on the topic of enhancing WP performance without db caching..

Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/

> -----Original Message-----
> From: wp-hackers-bounces@... [mailto:wp-hackers-
> bounces@...] On Behalf Of Robert Deaton
> Sent: Tuesday, April 17, 2007 11:25 PM
> To: wp-hackers@...
> Subject: Re: [wp-hackers] MySQL MEMORY worth using for an object cache?
>
> Okay, here's a few little tidbits from my experiences making WP scale
> while keeping it on a single server. These won't be useful for shared
> hosting, but the tidbits of information here might give you some
> insight into why I say what I say. :)
>
> 1). APC alone will do wonders. I know this is no good for shared hosts
> but if they got the hint, it'd be absolutely wonderful. As times goes
> on, more and more shared hosts are and will be adpoting APC,
> especially around the PHP6 launch which is supposed to have APC or an
> equivalent object caching backend built in.
>
> 2). Tweaking MySQL's internal query cache options and size can do
> wonders, however on a single box that expects to take a beating its
> not enough. Something is going to be needed on the frontend to help
> keep some of the load off the MySQL server for queries.
>
> 3). Don't bother using memcached on a single box. The APC backend for
> WP's object cache will outperform it anyday, you don't need a seperate
> daemon running to handle the requests.
>
> 4). Full page to disk caching does more harm than good on a server
> that is expecting a beating, especially one like digg or slashdot. The
> reason for this is that often times so many comments are posted that
> the server is constantly having to regenerate these pages and write
> them back to disk. Under heavy load, any moderately powered server
> won't usually have a hard time keeping up as far as CPU time goes, its
> file IO time, especially from disk (this is why APC helps immensely,
> WordPress loads a metric asston of files from disk otherwise). Using
> APC, the cost in CPU time for having to regenerate the pages easily
> outweighs the cost of having to pull the PHP source from disk. It
> isn't the recompilation that hurts WordPress the most, its disk IO.
>
> 5). lighttpd > Apache. The end.
>
>
> Now that those are out of the way, what can we do to help the average
> user on a shared host not kill the server?
>
> I am not opposed to checking for the existance of sysvsem, sysvshm,
> shmop, and APC, and attempting to use those as RAM storage. Writing
> backends for each of them is fairly straightforward, and when loading
> the object cache we could simply check for the existence of them and
> automatically load the first one that matches what we need. A constant
> in wp-config.php could be used to stop WordPress from automatically
> loading one of these backends.
>
> MySQL MEMORY for an object cache is also an option, but a potentially
> risky one, especially for things like posts as they differ largely in
> size, and we do have the fixed row limitation. I guess we could
> implement it as an object cache and see how it performs, and try to
> find a good balance between a size for all user's posts and a size
> that doesn't eat too much unnecessary memory. I'm not sure, due to the
> nature of only being able to store 255 chars in column, if using it to
> do full page caches ala WP-Cache is a good option.
>
> I believe there's some smaller optimizations that still may help. I
> personally believe throwing all the files together into one giant
> include would likely help. I also have a feeling that what Andy and I
> have been discussing recently as far as on-demand function loading may
> also help.
>
> Our MySQL queries can still likely be optimized a bit, and this is key.
>
> WP-Cache could use a rewrite from the ground up as well, imho. I wish
> I had more time to take this project under, but perhaps I will anyways
> in the coming weeks, or once summer starts.
>
> There's a few other things but I think I've fueled this fire plenty
> for the moment.
>
> --
> --Robert Deaton
> http://lushlab.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Paul Menard wrote:
> My
> understanding of APC is it just caches the pre-compiled php object code
> for Apache.

APC adds some additional function to PHP that can be used for object
caching.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Robert Deaton wrote:
> 4). Full page to disk caching does more harm than good on a server
> that is expecting a beating, especially one like digg or slashdot. The
> reason for this is that often times so many comments are posted that
> the server is constantly having to regenerate these pages and write
> them back to disk.

My experience has been the opposite. Make sure you have the latest
wp-cache, a previous had a bug where it would invalidate the cache for
spam comments and comments stuck in moderation. Perhaps turning
moderation in the situation would help as well, but I've never run into
that problem.

> I believe there's some smaller optimizations that still may help. I
> personally believe throwing all the files together into one giant
> include would likely help.

The only advantage to that over APC would be no stat calls to see if the
file has changed. You can actually tell APC not to check if a file has
changed, which means you have to restart it whenever you update a file,
but we found that had little or no effect.

I think a far larger benefit would come from simply dividing WP's files
up more so not everything is loaded for every request. A lot of
functions are used only for the backend, or only for RSS, or only on
non-RSS pages, and being smarter about what code we include I think can
have a big impact. This is different from on-demand loading.

> WP-Cache could use a rewrite from the ground up as well, imho. I wish
> I had more time to take this project under, but perhaps I will anyways
> in the coming weeks, or once summer starts.

It would be great if it supported multiple backends, like WP's own
cache. WP-cache + APC or memcache would be pretty potent.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Computer Guru wrote:
> my blog issues 36-44 queries per requested page (thanks to WP's badly designed db layer that makes all these plugins issue separate queries for their stuff).

That seems like a very odd thing to blame on WP, could you explain?

> Switch your WP tables to Innodb. WP (by default) doesn't require any MyISAM-specific features. Innodb is far faster for most SQL usages (the exception being constant real-time logging of server requests, etc)

I would recommend doing this, but only if you have innodb properly
configured. The key settings are innodb_buffer_pool_size,
innodb_additional_mem_pool_size, and innodb_flush_log_at_trx_commit.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Austin Matzko]

On 4/17/07, Matt Mullenweg <m@...> wrote:
> APC adds some additional function to PHP that can be used for object
> caching.

I think Mark Jaquith wrote this plugin[1] to take advantage of that a
while back.  Has anyone used it with recent versions of WP?

[1] http://comox.textdrive.com/pipermail/wp-hackers/2006-February/004472.html
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

On 4/17/07, Austin Matzko <if.website@...> wrote:
> On 4/17/07, Matt Mullenweg <m@...> wrote:
> > APC adds some additional function to PHP that can be used for object
> > caching.
>
> I think Mark Jaquith wrote this plugin[1] to take advantage of that a
> while back.  Has anyone used it with recent versions of WP?

This is what has been being discussed for using APC as an object cache backend.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

On 4/17/07, Matt Mullenweg <m@...> wrote:

> Robert Deaton wrote:
> > 4). Full page to disk caching does more harm than good on a server
> > that is expecting a beating, especially one like digg or slashdot. The
> > reason for this is that often times so many comments are posted that
> > the server is constantly having to regenerate these pages and write
> > them back to disk.
>
> My experience has been the opposite. Make sure you have the latest
> wp-cache, a previous had a bug where it would invalidate the cache for
> spam comments and comments stuck in moderation. Perhaps turning
> moderation in the situation would help as well, but I've never run into
> that problem.

Its been a while since I've had to use WP-Cache or tried to use it. It
very well may be better now, or my differences could have always been
related to heavy disk access anyways which made WP-Cache on top just
seem to slow down even more. I've found on most hardware sites I've
had to optimize for end up being IO-bound, not CPU bound, so in most
cases trying to keep things off disk IO doesn't hurt.

> > I believe there's some smaller optimizations that still may help. I
> > personally believe throwing all the files together into one giant
> > include would likely help.
>
> The only advantage to that over APC would be no stat calls to see if the
> file has changed. You can actually tell APC not to check if a file has
> changed, which means you have to restart it whenever you update a file,
> but we found that had little or no effect.
>
> I think a far larger benefit would come from simply dividing WP's files
> up more so not everything is loaded for every request. A lot of
> functions are used only for the backend, or only for RSS, or only on
> non-RSS pages, and being smarter about what code we include I think can
> have a big impact. This is different from on-demand loading.

This is actually a part of what Andy and I have been talking about
recently. The discussion came up over a year ago as well, but nothing
ever came of it.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers