I've got a site where we want recency to be the most important characteristic but also count in votes from Fivestar, "favorites" using the flag module (site specific plugin), number of views, and number of replies via comments.

I'm curious if you have any advice about the ratios of some of these elements. Threads tend to get about 2 comments each.

My initial thought:

  • Creation of a thread: 1,000 energy units
  • Posting a comment: 50 units
  • Viewing a node: 1 unit
  • Voting with fivestar: -20 units, -10 units, +1 unit, +10 units, +20 units respectively for 1star, 2stars, 3stars, 4 stars, 5 stars
  • Favoriting a post with flag module: 30 units

The second piece is about the cut-off energy. Do you have any general advice on that point?

I ask this question to get personal help but also because it seems like any "rules of thumb" in this area could be extremely valuable. The README.txt talks about suggested half-life periods and decay granularity.

Comments

skiminki’s picture

Your setup would greatly emphasize creation of a thread. One way to think about is that 20 comments equals 1 creation (roughly). I think that there's no shortcut for defining these values but to try to track the site activity and heuristically try to think which threads should be hotter than the others, and try to reverse engineer proper values from there. Once the site is active, you can always fine-tune the energy values afterwards.

About the cut-off energy. Basically, the cut-off energy threshold is performance optimization. Don't set it so high that nodes that get some meaningful activity don't get the energy value reset to zero at the next cut-off. What I mean is that if the node has 0 energy initially and gets 5 views (=1 unit) per minute, and cut-off (10 units) is performed every minute, the node will never have more than 5 units of energy because of the cut-off.

Having hundreds of nodes, or maybe even tens of thousands of nodes in the radioactivity table is probably no big deal for most sites, as usually the operations are really straightforward, like get top 10 nodes of some type ordered by energy etc. So keeping it reasonably small is probably safe. The idea is to remove the entries that absolutely no-one is interested in, as they're not meaningful. Think like: "If the energy is below the threshold, it's effectively 0." Try setting the threshold initially low (like half a view) and only raise it if you have performance problems.

Maybe some of these thoughts should be included in the documentation. Anyways, hope this helps.

greggles’s picture

Very helpful. As I experiment more I will try to refine the results into some good documentation.

I totally agree about comparing the frequency of the events and assigning points from there - unfortunately we don't know how often some of these events occur in the current system.

Sutharsan’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

Issue triage: Closing issue, the 6.x branch is no longer maintained.

If you believe this issue is closed in error, feel free to re-open.

greggles’s picture

Version: 6.x-1.x-dev » 8.x-3.x-dev
Status: Closed (outdated) » Active

This still seems like a relevant documentation task for 8.x.

Sutharsan’s picture

I agree, this is useful. Also the relation between Granularity and cron should be explained:

Granularity is the time between energy calculations. For development, where cron is executed manually, it is useful to set the Granularity low. But for a production environment, the granularity should be set to a value equal or higher than cron. If you want your popularity per day, set the Granularity to 86400 seconds (=24 hours). Cron will now re-calculate the popularity once per day.

Sutharsan’s picture

Status: Active » Fixed

The readme and on-line documentation (https://www.drupal.org/docs/contributed-modules/radioactivity) have now more detailed description of the various profiles and their configuration options.

Closing the issue now. If you need support and want more information, feel free to open a new support issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.