Performance storage backends

I was a fan of eAccelerator too. I found it to be faster and more memory efficient than APC.

However, with the later versions of PHP, I have found eAccelerator to be very very unstable, and crashes all the time. APC is guaranteed to track PHP's development because it is maintained by the same group of people. eAccelerator has been practically unmaintained for about 2 years.

But, if you want to add this feature, you have to come up with a clean compact patch that integrates well with the rest of the code, for Drupal 5.x, 6.x and 7.x.

Better than function_exists(), we can take it one step further and split the backends to their own performance.backend.inc and have them totally separated out.

Sounds good... I'll try to make a patch (d6 and maybe 7) but first I wanna know how to split

I dig into code and found a lot of variable_get with performance_summary_apc which better to replace with performance_summary_accel or some

Is DB as backend should be separated too?

Suppose better to use .inc with definition of class performance_backend so constructor check availability of backend
Next it bring more clean code in .module

First patch just .install fix

PS: Not agree - eaccelerator still actively maintained and works without problems

Good start.

But why use 1 and 2? Why not 'apc', 'eaccel', 'memcache' so it is descriptive?

As I said, we can have an include based on the backend engine, for example performance.$engine.inc, where $engine is one of the above.

Have you considered writing an eAccelerator plugin for Cache Router? That might be easier than reinventing the wheel.

(Edit)

In fact, somebody else already did. See http://drupal.org/node/331129

@pillarsdotnet

You are mistaken and missing the point about this module.

The devel and performance logging modules do not depend on, nor will it, on cacherouter.

They are development/system administration tool, for gathering site statistics. They are not designed for regular use on live sites.

@kbahey I think so it's not mistake - cacherouter is just backend for storage. Simple set-get-clean object cover for different engines. It's an interesting aproach...

I make eaccel backend for cache router and see devel which compatible with eaccel, memcache and others

As you say it's not only development tools but administrative too - performance statistics could be gathered from all supporting projects into one place (for example memcache) and controled from single control panel

I dig into code and see that today only performance_log_summary_apc (propose to rename it)
It looks like commulative counter but current realization is average but not real (not sequental)

In cacherouter this problem was solved very dirty
for eample memcache can use memcache_increment() , xcache xcache_inc()

Next about config and UI

1) Is DB just a one of others backends - suppose Yes
2) Do we need to choose more then one backend - YES
3) Config per backend - YES (apc eaccelerator xcache DB - no UI to configure, memcache need but possible to use module memcache)
4) Only one option (checkbox) - enabled or not every backend if available

Proposed logic
- get array of enabled backends from variable_get, check for availiability of file, php-extension, backend
- load apropriate $backend.inc files (in cacherouter they are just inherited overrided classes inside)
- units (functions, modules .. whatevere) call a performance_[action, trigger, function, hook]
- backend handlers store gathered data

Challenge
- choose what kind of object (variable) holds-knows active backends and there connections (memcache for ex)
- procedural or object realization proposed?
- write a code :)

Any thoughts?

PS: cacherouter is object oriented model where config stored in settings.php file and same dependency is bad, IMO

No. I don't want the performance.module to depend on another module, whether it is memcache or cacherouter.

Locking can be an issue, yes. If you have a solution, let us see some sample code to solve it.

Yes, we can have more than one backend. Although which combination is important. We can have DB + one other backend (either APC, eAccelerator, Xcache or memcache). Or we can have APC with memcache.

So, let the user choose the backend to enable via a check box. We can grey out the ones we detect are disabled. No point in enabling something not on the system.

As I said, I only care about APC, database (both of them exist) and memcache (does not exist yet). The work would be to modularize them and make them pluggable, and then add the other ones if there is interest.

I am interested in performance logging of my site and don't have APC installed. Instead I have eaccelerate. Having devel woark with eaccelerate or other modules, would help.

I am also taking a look to standardize on one caching solution for both the backend and debugging.

Just $.02 from another user :)

Subscribing. Is there any updates on this? I only have memcache installed but not APC.

Main problem is locking and I found no solution, another problem with memcache - listing of keys (data could be lost)

I'm going to test new http://pinba.org as presentation was great