Quantcast

ZF2: Zend Cache refactoring

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ZF2: Zend Cache refactoring

Marc Bennewitz (private)
 Hello all,

I finished the proposal for a complete refactoring of Zend Cache
to solve current limitations of the current implementation
and to make it more dynamic by a better performance.
You are really welcome to make comments, suggestions and extensions to
them!
Greetings,
Marc
Wiki entry:
http://framework.zend.com/wiki/display/ZFPROP/Zend+Cache+2.0+-+Marc+Bennewitz
<http://framework.zend.com/wiki/display/ZFPROP/Zend_Service_Chartlyrics+-+Maghiel+Dijksman>
GitHub: http://github.com/marc-mabe/zf2/tree/cach
<http://github.com/maghiel/Zend_Service_ChartLyrics>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Marc Bennewitz (private)
 oh yes there were some mistakes on copying the urls.

This are the right links:
Proposal:
http://framework.zend.com/wiki/display/ZFPROP/Zend+Cache+2.0+-+Marc+Bennewitz
GitHub: http://github.com/marc-mabe/zf2/tree/cache

Greetings
Marc

> looks interesting, nice piece of work on the proposal!
>
> I am swamped with all the stuff at work but i would like to help out
> with the efforts.
>
> I thought that caching interface was waaaay to complicated in ZF : ) I
> think consistency and clarity is the key here.
>
> I am not sure how does the code look like as cant get it out now, can
> you please send git repo again? something did not work for me with the
> url.
>
> would like to see the code, thanks
>
> Art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Marc Bennewitz (private)

> There is **load of code in there!  :-) I can see that some adapters
> are ported or copied from zf1 but its ok shows what goes where.
The ZF1-Cache-Backends which are storing the data it's self are
Storage\Adapter's now.
(The TwoLevels Backend doesn't store data it's self and only applies
special behaviors it's moved to Storage\Plugin\Levels)

The most of the storage adapters aren't completely refactored - only of
Filesystem and Memory all tests are passing for now.

> I hope you dont mind if i bother you with some of my thoughts. Just a
> few ideas:
>
> 1. Not sure about plugin VS decorator. I think that it is good idea to
> provide extra features via decorators. If it does not cause trouble
> with edge cases its the way to go. Im just not sure would adapter
> interface not be enough? should users be accessing storage adapter
> directly if they have cache object instance? i know it adds potential
> flexibility but i am not sure if users would not get confused and
> started using it in some sick ways.
The plugin system is based on the decorator pattern (The name is debatable)
You have to know what you would do with the cache. If you don't need
additional functionalities nobody will constrain you.

>
> To me, the cleanest way would be to wrap adapter with set of
> decorators and forget about the whole thing passing one instance as
> interfaces. No one should care if they get adapter or decorator as
> only adapter interface would be passed around. How do you think? i
> mean it is a sort of restriction but could make things bit simpler.
> That was the part i did not like about ZF1 cache, its just too many
> object types involved every object returns some handlers to frontend,
> backend, at the end you dont know how to cache anything ;- ) Id keep
> it simple.
The plugin interface extends the adapter interface - you can use it at
all where an adapter is required.
Therefore it's equal if you have an instance of a plugin or of an
adapter directly.

>
> The only problem you get if you would like to implement something like
> a adapter fallback. In case of connection failure local file cache is
> used not the original one. Then the fallback adapter would have to be
> the first adapter wrapping the storage as otherwise you could not
> replace the delegate without loosing some decorators.
>
> serializeAdapter( fallbackAdapter( memcachedAdapter() ) )
No, you have to set the right order of the plugins and the fallback
function doesn't stores data's it's self and therefore is a plugin:

fallbackPlugin(
  'storage' => MemcachesAdapter
  'fallback_storage' => SerializerPlugin( FilesystemAdapter )
)

-> The fallback is a plugin and handles connection failures of the
storage adapter to the fallback adapter
-> Serialization is build-in functionality of the memcached adapter and
the SerializerPlugin isn't needed
    but it's needed for the fallback adapter


>
> Same with multilevel case, it would need a thought but could work ok i
> guess. If not maybe leave adapters with decorators and if there is
> need for more complex logic do it in separate classes.
same as above

>
> 2. maybe it would make sense to namespace or prefix options in some
> way. Probably some of the plugins would accept more options for
> example if you have multilevel cache and you want to make sure item
> gets stored in all levels or the opposite you do not want it. Then you
> could control it in set call via options i guess. Problem if each
> adapter has same option names they may be used improperly as they flow
> down the decorators chain. On the other hand that breaks the concept
> of not knowing what plugins are in the chain so could be only used as
> hints to the cache system but no guarantee could be given.
I regard that options names are different if they have a different
meaning but you are right for plugins handling more than one storages
like the levels plugin - there I use only the first internal used
adapter to flow down or get up. If you would like to get/set an option
of one of the others internal adapters you need the adapter objects.

$fastCache = Cache\StorageFactory::factory(array(
    'adapter' => 'Memcached',
    'options' => ...
));
$slowCache = Cache\StorageFactory::factory(
    'adapter' => 'Filesystem',
    'plugins' => array('Serializer', 'IgnoreUserAbort')
    'options' => ...
);
$levelsCache = Cache\StorageFactory::pluginFactory('Levels', array(
    'storages' => array($fastCache, $slowCache)
));

>
> I believe it will be good no matter what but simplicity is what i
> missed the most in zf1 cache : -)
In my eyes it's very simple to use and to add functionalities.

>
> hope what i wrote makes any sense : -)
>
> cheers
>
> Art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Marc Bennewitz (private)

> > > The only problem you get if you would like to implement something like
> > > a adapter fallback. In case of connection failure local file cache is
> > > used not the original one. Then the fallback adapter would have to be
> > > the first adapter wrapping the storage as otherwise you could not
> > > replace the delegate without loosing some decorators.
> > >
> > > serializeAdapter( fallbackAdapter( memcachedAdapter() ) )
> > No, you have to set the right order of the plugins and the fallback
> > function doesn't stores data's it's self and therefore is a plugin:
> >
> > fallbackPlugin(
> >   'storage' => MemcachesAdapter
> >   'fallback_storage' => SerializerPlugin( FilesystemAdapter )
> > )
>
> yes i know that in your design plugin
> delegates calls and maybe  i should have chosen different naming like
> fallbackAdapterDecorator or whatever and yes it would need constructor
> talking 2 adapters ..... missed that out as well : -)
My intentions for the naming is the following:
- to implement caching you need a cache storage -> Zend\Cache\Storage
  - the cache storage needs min. 1 storage adapter ->
Zend\Cache\Storage\Adapter
  - to change the behavior or to add functionalities to the storage
    you can use an unlimited set of storage plugins ->
Zend\Cache\Storage\Plugin
- all classes within the namespace Zend\Cache\Storage
  implements Zend\Cache\Storage\Adapter, so where ever a cache storage
is needed
  you can use all class instances of this namespace

> i mean i looked at it for maybe 30 mins and i think i know how to
> use it so yes it is easy to use i would say. Seems simplier than zf1 any way.
>
> Just thinking aloud : )
>
> Ps is there particular
> section you would like to help with? im quite busy but who knows maybe
> ill have half day off on the coming long weekend ; -)
>
> Art
Every little bit helps ;)

Currently I'm working on tests of the already refactored classes and
reducing some code doubling.
If you like you can start refactoring of one of the following classes:
Adapters: Sqlite, Xcache, ZendServer*, ZendPlatform, WinCache, Apc (use
trunk of ext/apc)
Plugins: Levels, Tagging,
Pattern: CaptureCache
-> If you have ZendServer, ZendPlatform or Win+IIS (WinCache) I would be
happy if you could work on this adapters ;)

Have a nice day
Marc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Marc Bennewitz (private)
Hi Renan,

answers in line.

PS: please reply to mailing list if you have ideas to make things better, so all other members can read it, too ;)

My intentions for the naming is the following:
Hi Marc,

First of all, thanks and congratulations for your work on zf2-cache proposal.

I use Zend_Cache in every application i code, so i have some doubts
and suggestions to you. If anything i say does make sense, please be
patient ;-)

I see we have this tree:
- Pattern
- Storage
    - Adapter
    - Plugin
    - Options
I'm not saying about classes or objects, but about "things".
I think Pattern could be a optional argument to Storage, like plugins
and options.
I mean a cache object in my mind could have four things:
    - Adapter (required, with a default adapter, maybe file)
    - Pattern (optional)
    - Plugin (optional)
    - Options (optional)
There is a main difference between Storage and Pattern:
Storages has a fixed API (get/set/replace/add/exists/...) but Patterns are not.
Patterns are implementing it's own API and in part of the CaptureCache-Pattern which implements it's own file storage (old static backend) because it doesn't make sense to use the capture pattern with an other storage or creating a storage only usable by the capture pattern.

Maybe you hate current zend_cache_frontend in zf1, like me :-P
but i don't see reason to take this away, it could be just a optional
configuration in my cache object.
The most open issues are in base of the frontend/backend structure !

I read your code, it's nice, but it's not easy to understand, not easy
for me, a commom developer :-) You tried show some simple usage in
proposal, but, believe, people get confused when they have to call
factories with more than 2 arguments, that those may be objects or
arrays, hehehe

The point is i think the object cache could handle those parts:
adapters, patterns, plugin and options. I don't have a solution, but i
think zf2-cache should be easy like this:

$cache = new Zend_Cache();
$cache->save('name', $value);
$cache->get('name');
1. As you noted an adapter is required, you have to give an adapter.
2. ZF 2.0 Zend_Cache would be moved to Zend\Cache\Cache

I implemented a class to simplify instantiating and handling plugins.
$cache = new \Zend\Cache\Storage(aray(
    'adapter' => 'Filesystem',
    'plugins', // optional
    'options' // optional
));
// the key is optional and will be detected on the last used key
$cache->save($value, 'name');
$cache->get('name');

I think this is our goal, to make things easy-to-use, even we have to
code a lot.

sorry if you feel me rude, i'm not, it's just me bad english :-P
I'm not a native English speaker, too.

Marc, i'm working on tests and doc to Zend_Service_Ebay for zf1, but
i'm interested to work on zf2-cache. If you have plans and tasks
to-do, you may assign to me soon, after i get ebay done, next week i
hope ;-)
There are a lot of todo's rewriting it.

I already wrote it to Artur:
If you like you can start refactoring of one of the following classes:
Adapters: Sqlite, Xcache, ZendServer*, ZendPlatform, WinCache, Apc (use
trunk of ext/apc)
Plugins: Levels, Tagging,
Pattern: CaptureCache
-> If you have ZendServer, ZendPlatform or Win+IIS (WinCache) I would be
happy if you could work on this adapters ;)

Have a nice day
Marc

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Artur Ejsmont
Hi guys

Im confused about this bit:

// the key is optional and will be detected on the last used key
$cache->save($value, 'name');
$cache->get('name');

I did not get what you meant here : -)

I agree that factories may be overwhelming especially if parameters can be a mixture of objects and arrays etc. 

I think idea with list of plugins/decorators that will be used it good and seems simple enough. It may not be so simple if some of these plugins also need parameters passed to their constructors but i have to play with it more to see where/if it can break.

thanks

Art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ZF2: Zend Cache refactoring

Renan de Lima
In reply to this post by Marc Bennewitz (private)
On 30 July 2010 11:15, Marc Bennewitz <[hidden email]> wrote:
> Hi Renan,
>
> answers in line.
>
> PS: please reply to mailing list if you have ideas to make things better, so
> all other members can read it, too ;)

ok ;-)

> I read your code, it's nice, but it's not easy to understand, not easy
> for me, a commom developer :-) You tried show some simple usage in
> proposal, but, believe, people get confused when they have to call
> factories with more than 2 arguments, that those may be objects or
> arrays, hehehe
>
> The point is i think the object cache could handle those parts:
> adapters, patterns, plugin and options. I don't have a solution, but i
> think zf2-cache should be easy like this:
>
> $cache = new Zend_Cache();
> $cache->save('name', $value);
> $cache->get('name');
>
> 1. As you noted an adapter is required, you have to give an adapter.

file adapter as default can work, in the other hand the component
could detect apc or others adapters available by default in
environment

> 2. ZF 2.0 Zend_Cache would be moved to Zend\Cache\Cache

ok

> I implemented a class to simplify instantiating and handling plugins.
> $cache = new \Zend\Cache\Storage(aray(
>     'adapter' => 'Filesystem',
>     'plugins', // optional
>     'options' // optional
> ));

that's perfect, i just didn't get this usage mode, imho this way the
component can be popular, because it's easy

> I already wrote it to Artur:
> If you like you can start refactoring of one of the following classes:
> Adapters: Sqlite, Xcache, ZendServer*, ZendPlatform, WinCache, Apc (use
> trunk of ext/apc)
> Plugins: Levels, Tagging,
> Pattern: CaptureCache
> -> If you have ZendServer, ZendPlatform or Win+IIS (WinCache) I would be
> happy if you could work on this adapters ;)

ok, i'm gonna start soon, i'll ping you

thanks
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Renan de Lima
In reply to this post by Artur Ejsmont
Hi all,

On 30 July 2010 12:04, Artur Ejsmont <[hidden email]> wrote:
> Hi guys
> Im confused about this bit:
>
> // the key is optional and will be detected on the last used key
> $cache->save($value, 'name');
> $cache->get('name');
>
> I did not get what you meant here : -)

hehehe, no problem, i mean we could provide a easy way to make cache objects
when i think about cache, i think i wanna get and set data there, at
first moment i don't care about filters, plugins, options, i just want
that my cache object save and restore data

$cache = new Zend\Cache();
$cache->set($name, $value);
$cache->get($name);

even noob programmers can use cache this way

> I agree that factories may be overwhelming especially if parameters can be a
> mixture of objects and arrays etc.
> I think idea with list of plugins/decorators that will be used it good and
> seems simple enough. It may not be so simple if some of these plugins also
> need parameters passed to their constructors but i have to play with it more
> to see where/if it can break.

those concept also looks nice to me, the functionalities we have it's
very important for big applications, my two cents was about simple
usage

an example, when i code in symfony, cache is default, i don't have to
configure it, ok, they have a sandbox, another think zf should have,
but the usage is easy, *if* you want you change the configuration and
explore the options and extras of component

when i get the proposal it seems zf2-cache shows up the hardcode to
user, but Marc shows us in last reply we have an easy mode to create
cache object
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Marc Bennewitz (private)
In reply to this post by Artur Ejsmont


On 30.07.2010 17:04, Artur Ejsmont wrote:
Hi guys

Im confused about this bit:

// the key is optional and will be detected on the last used key
$cache->save($value, 'name');
$cache->get('name');
- "save" was wrong and should be "set" ;)

I was just to say that the cache id/key of set/save method is the second parameter because it's optionally.
If you don't give it, the last used cache id/key will be used.

e.g:
$cache->get('myKey');
$cache->set($value);  // -> stores to 'myKey'


I did not get what you meant here : -)

I agree that factories may be overwhelming especially if parameters can be a mixture of objects and arrays etc. 

I think idea with list of plugins/decorators that will be used it good and seems simple enough. It may not be so simple if some of these plugins also need parameters passed to their constructors but i have to play with it more to see where/if it can break.
The class Zend\Cache\Storage is only a helper class (implements Zend\Cache\Storage\Plugin) .
With it you don't need to instantiate by factories and it adds some methods to handle plugins.


thanks

Art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: ZF2: Zend Cache refactoring

Thomas D.
In reply to this post by Marc Bennewitz (private)
Hi,

could you tell us something about the support of clusters in Zend Cache 2.0?
For example, does Zend Cache supports a cluster of memcached servers?

When it would support that, I would expect something like a consistent
hashing algorithm. If you put something in the cache, e.g.

$cache->save($date, $cacheId);

Zend Cache should estimate which server should be used. So the user can use
Zend Cache the normal way, the user doesn't need to know, that there a more
than one memcached servers in use.

If this isn't currently possible, does Zend Cache 2.0 architecture allow
such an extension?

Or would you say, this is has nothing to do with Zend Cache and should be an
own component?


--
Regards,
Thomas


Regards,
Thomas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Renan de Lima
On 2 August 2010 16:09, Thomas D. <[hidden email]> wrote:

> Hi,
>
> could you tell us something about the support of clusters in Zend Cache 2.0?
> For example, does Zend Cache supports a cluster of memcached servers?
>
> When it would support that, I would expect something like a consistent
> hashing algorithm. If you put something in the cache, e.g.
>
> $cache->save($date, $cacheId);
>
> Zend Cache should estimate which server should be used. So the user can use
> Zend Cache the normal way, the user doesn't need to know, that there a more
> than one memcached servers in use.

in memcached cluster is native,
http://www.php.net/manual/en/memcached.addserver.php
options weight is used to control the probability of the server been selected
add-server operation is available since zf1

> If this isn't currently possible, does Zend Cache 2.0 architecture allow
> such an extension?
>
> Or would you say, this is has nothing to do with Zend Cache and should be an
> own component?

for this case i see a solution using Zend\Cache\TwoLevels multiple times
this adapter is a interface for 2 caches, that choose internal adapter
calculating filling of each one
it's possible send to TwoLevels instance another TwoLevel instance,
working like a "MultiLevels"

maybe a new adapter in replace of TwoLevels could be done, just to
make this explicit, or to use another parameters for probability
calculating

my $ 0.02

--
Renan de Lima
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Artur Ejsmont


maybe a new adapter in replace of TwoLevels could be done, just to
make this explicit, or to use another parameters for probability
calculating



yes i guess it would make sense to have adapter/plugin for that reason only.

As good as memecache is we could come up with a nice implementation so it would work for other engines in a consistent and simple to use way

art

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

Marc Bennewitz (private)
In reply to this post by Marc Bennewitz (private)


e.g:
$cache->get('myKey');
$cache->set($value);  // -> stores to 'myKey'




Ok thats what i was afraid of ... i myself would not recommend this as it may cause problems if key is kept on some sort of stack or whatever you may end up saving value to the wrong key (in some user code where they have ifs and exceptions etc.

I know in 95% of normal users it will not be a problem but is it worth it?

To keep it simple i would just require explicit key on set ... seriously its not such effort to add the key in set ... in most cases you will have it in local scope any way.

or did i misunderstood the concept entirely?

art
The optional cache key/id is a feature of 1.x. I never used it but I don't know how many people do.
-> I don't like to remove features in Zend Cache 2.0 because we should do a poll to see how many people using it before do a remove.

Greetings
Marc

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

David Moring
We actively use the tag feature, a lot.

--d

On 08/03/2010 02:18 AM, Marc Bennewitz wrote:

>
>>
>>     e.g:
>>     $cache->get('myKey');
>>     $cache->set($value); // -> stores to 'myKey'
>>
>>
>>
>>
>> Ok thats what i was afraid of ... i myself would not recommend this as
>> it may cause problems if key is kept on some sort of stack or whatever
>> you may end up saving value to the wrong key (in some user code where
>> they have ifs and exceptions etc.
>>
>> I know in 95% of normal users it will not be a problem but is it worth it?
>>
>> To keep it simple i would just require explicit key on set ...
>> seriously its not such effort to add the key in set ... in most cases
>> you will have it in local scope any way.
>>
>> or did i misunderstood the concept entirely?
>>
>> art
> The optional cache key/id is a feature of 1.x. I never used it but I
> don't know how many people do.
> -> I don't like to remove features in Zend Cache 2.0 because we should
> do a poll to see how many people using it before do a remove.
>
> Greetings
> Marc
>


david.vcf (139 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2: Zend Cache refactoring

David Moring
ok, my bad on the tags v id/key, we do use the id/key feature, but we
can write around it, if removed.  We gotta have the tags--we use them to
clean up old data...we are all storage cloud and storage costs.

On 08/05/2010 02:07 PM, David Moring wrote:

> We actively use the tag feature, a lot.
>
> --d
>
> On 08/03/2010 02:18 AM, Marc Bennewitz wrote:
>>
>>>
>>> e.g:
>>> $cache->get('myKey');
>>> $cache->set($value); // -> stores to 'myKey'
>>>
>>>
>>>
>>>
>>> Ok thats what i was afraid of ... i myself would not recommend this as
>>> it may cause problems if key is kept on some sort of stack or whatever
>>> you may end up saving value to the wrong key (in some user code where
>>> they have ifs and exceptions etc.
>>>
>>> I know in 95% of normal users it will not be a problem but is it
>>> worth it?
>>>
>>> To keep it simple i would just require explicit key on set ...
>>> seriously its not such effort to add the key in set ... in most cases
>>> you will have it in local scope any way.
>>>
>>> or did i misunderstood the concept entirely?
>>>
>>> art
>> The optional cache key/id is a feature of 1.x. I never used it but I
>> don't know how many people do.
>> -> I don't like to remove features in Zend Cache 2.0 because we should
>> do a poll to see how many people using it before do a remove.
>>
>> Greetings
>> Marc
>>
>
>
--
David Moring
Managing Partner
Applied Autonomics LLC
Organizing information in new and interesting ways

david.vcf (139 bytes) Download Attachment
Loading...