[development] Split up the cache table

Gerhard Killesreiter gerhard at killesreiter.de
Fri Aug 4 11:31:53 UTC 2006

Dries Buytaert wrote:
> On 03 Aug 2006, at 18:52, Gerhard Killesreiter wrote:
>> Dries Buytaert wrote:
>>> On 03 Aug 2006, at 00:39, Gerhard Killesreiter wrote:
>>>>          SELECT     INSERT     UPDATE    DELETE
>>>> filter:   0.002      0.005      0.002     0.087
>>>> page:     0.007      0.009      0.003     0.188
>>>> menu:     0.011      0.014      0.016       n/a
>>>> rest:     0.002      0.007      0.004       n/a
>>> Is that in seconds or ms?
>> That's seconds, ie your sql query to get the menu cache will on 
>> average contribute 0.011 seconds to the page build time, if you use my 
>> patch.
> So we improve performance by 3ms?  That is rather small-ish, not?

No, by 7ms per cache_get, you need to look at the other table, which 
compares the average times of the SELECTs (3ms vs 10ms). I agree that it 
is a small contribution if you consider page creation time (the total 
depends on how many cache_gets happen on a page), but if you consider 
the time spent on the mysql server it is quite a lot because the 
cache_get queries are run that often.

To get some idea of how much this change affects a the page generation 
time, we look at the number of cache_gets from the cache_menu table, 
10997. That means we sampled 10997 page views (remember we only sample 
10% of all page views). Over the same time we've had a total of 298891 
cache_get function calls. That means that there are on average 298891 / 
10997  = 27 cache_get calls per page. From this I infer that we save 7ms 
* 27 = 189 ms per page view. Not /that/ bad.


More information about the development mailing list