« Return to Thread: Caching of describeTable
Re: Caching of describeTable
by Bill Karwin from Zend
::
Rate this Message:
It's true that requiring a describe() on every page request is costly.
I've seen reports that performance is poor for describe and other usage
of the INFORMATION_SCHEMA virtual tables, in MySQL. Not surprising that
the feature was not designed for high performance, under the assumption
that will be queried infrequently.
Caching the metadata automagically is one solution. TTL is probably of
the least expensive way to get some benefit out of the cache, but allow
for changes to occur without requiring manual intervention to update the
app's view of the metadata. There should also be some method to purge
the cache before the TTL expires. I'd hate to be that developer telling
the Marketing VP that we've changed the schema, but the app won't notice
the change for another two hours!
One should be able to tune the TTL down to zero or near zero during
development. Schema changes are much more frequent during development,
and making the TTL tunable would be the most transparent way to handle this.
I don't think putting schema details into the code is the best
solution. This would be equivalent to putting a schema description into
a config file, which is one thing we're committed to avoiding in Zend
Framework. With that solution, it is difficult to keep the schema
description in sync with the actual schema. Letting the Db component
refresh this for you and cache the results for you would be a better
solution.
Bill
Andi Gutmans wrote:
> I think there are a few options here which we discussed in the past:
> a) Use Zend_Cache to cache the info with a TTL.
> b) Implement a very lightweight Zend_Db specific cache with TTL.
> c) Auto-generate classes (i.e. manual update). Theoretically that and Cache
> are similar solutions as Cache can also be manually generated.
>
> Anyway, Bill is working right now to come with a suggestion for what the
> scope of Zend_Db is and if we need an additional layer, what that would be.
> This issue will definitely be taken into account.
>
> Thanks.
>
> Andi
>
>
>> -----Original Message-----
>> From: Shahar Evron [mailto:shahar.e@...]
>> Sent: Monday, January 01, 2007 6:15 AM
>> To: fw-db@...
>> Subject: [fw-db] Caching of describeTable
>>
>> Hi,
>>
>> Maybe I just need to RTFM but this one is a quickie: Is there
>> a caching solution for Zend_Db_Adapter_xxx::describeTable() ?
>>
>> That one gets called quite frequently, and is very unlikely
>> to change in production environemtns. Caching it somehow
>> would be a smart idea.
>>
>> If nobody has suggestions, I'll do some hacking later and
>> post an article about it.
>>
>> TIA,
>>
>> Shahar.
>>
>>
>
>
>
I've seen reports that performance is poor for describe and other usage
of the INFORMATION_SCHEMA virtual tables, in MySQL. Not surprising that
the feature was not designed for high performance, under the assumption
that will be queried infrequently.
Caching the metadata automagically is one solution. TTL is probably of
the least expensive way to get some benefit out of the cache, but allow
for changes to occur without requiring manual intervention to update the
app's view of the metadata. There should also be some method to purge
the cache before the TTL expires. I'd hate to be that developer telling
the Marketing VP that we've changed the schema, but the app won't notice
the change for another two hours!
One should be able to tune the TTL down to zero or near zero during
development. Schema changes are much more frequent during development,
and making the TTL tunable would be the most transparent way to handle this.
I don't think putting schema details into the code is the best
solution. This would be equivalent to putting a schema description into
a config file, which is one thing we're committed to avoiding in Zend
Framework. With that solution, it is difficult to keep the schema
description in sync with the actual schema. Letting the Db component
refresh this for you and cache the results for you would be a better
solution.
Bill
Andi Gutmans wrote:
> I think there are a few options here which we discussed in the past:
> a) Use Zend_Cache to cache the info with a TTL.
> b) Implement a very lightweight Zend_Db specific cache with TTL.
> c) Auto-generate classes (i.e. manual update). Theoretically that and Cache
> are similar solutions as Cache can also be manually generated.
>
> Anyway, Bill is working right now to come with a suggestion for what the
> scope of Zend_Db is and if we need an additional layer, what that would be.
> This issue will definitely be taken into account.
>
> Thanks.
>
> Andi
>
>
>> -----Original Message-----
>> From: Shahar Evron [mailto:shahar.e@...]
>> Sent: Monday, January 01, 2007 6:15 AM
>> To: fw-db@...
>> Subject: [fw-db] Caching of describeTable
>>
>> Hi,
>>
>> Maybe I just need to RTFM but this one is a quickie: Is there
>> a caching solution for Zend_Db_Adapter_xxx::describeTable() ?
>>
>> That one gets called quite frequently, and is very unlikely
>> to change in production environemtns. Caching it somehow
>> would be a smart idea.
>>
>> If nobody has suggestions, I'll do some hacking later and
>> post an article about it.
>>
>> TIA,
>>
>> Shahar.
>>
>>
>
>
>
« Return to Thread: Caching of describeTable
| Free embeddable forum powered by Nabble | Forum Help |
