Memcache acceleration (D6 port)
| Project: | Radioactivity |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | skiminki |
| Status: | closed |
Jump to:
Currently, radioactivity issues one insert-or-update to db for each node profile where node view energy is defined, per node view. For example, 3 different node popularity profiles means 3 insert-or-updates for each node view. For busy sites, this might pose some problems.
One possibility of eliminating these insert-or-updates is memcached-based acceleration. Instead of insert-or-updates per each view, an entry is written into memcache. Cron runs could process these entries and update db with only a few combined insert-or-updates. In essense, after this we'd have a small amount of communication with memcached per node view, and insert-or-update for each decay profile per cron-run. Sounds promising.
Let's investigate if this could work!

#1
Ok, committed initial version of memcache acceleration into 5.x development branch:
http://drupal.org/cvs?commit=182998
To enable memcache acceleration:
To verify that memcache acceleration is really working, try:
You should see that radioactivity-related sql activity is shifted from node views to crons.
#2
This runs now in production and seems to be working as expected. So let's say this is fixed. Thanks to Uusi Suomi for sponsoring the development!
#3
#4
Automatically closed -- issue fixed for 2 weeks with no activity.
#5
Is it committed to D6 too?
#6
Nope, this is not yet ported to D6. Changed the title and version to reflect this feature request.
#7
Subscribing
#8
D6 port implemented and committed: http://drupal.org/cvs?commit=243816
If you encounter problems, please re-open this issue.
#9
Note that the D6-version stores all energy events into memcached and processes them at cron runs. The D5 version does this only for node views. Also, you can review the pending events in /admin/debug/radioactivity/memcache provided that radioactivity_debug is enabled (D6 only).
#10
Automatically closed -- issue fixed for 2 weeks with no activity.