« Return to Thread: Caching of describeTable
Re: Caching of describeTable
by GavinZend
::
Rate this Message:
Where the schema information goes is more a matter of perspective and
preference, whether cached via Zend_Cache, or cached the Qcodo way.
Qcodo has a much more robust API for managing changes and
programmatically interacting with the schema, than just a serialization
of describeTable()'s output cached in Zend_Cache, but then I'm bordering
on comparing an apple pie to an orange ;)
BTW, the solutions I've seen using TTL's have extra complexity to work
around distributed environments (e.g. more than one edge/web server).
Cheers,
Gavin
Bill Karwin wrote:
> 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.
preference, whether cached via Zend_Cache, or cached the Qcodo way.
Qcodo has a much more robust API for managing changes and
programmatically interacting with the schema, than just a serialization
of describeTable()'s output cached in Zend_Cache, but then I'm bordering
on comparing an apple pie to an orange ;)
BTW, the solutions I've seen using TTL's have extra complexity to work
around distributed environments (e.g. more than one edge/web server).
Cheers,
Gavin
Bill Karwin wrote:
> 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.
« Return to Thread: Caching of describeTable
| Free embeddable forum powered by Nabble | Forum Help |
