Will Organic Groups scale?
I had experience using the Orgnanic Groups module with Drupal version 4.6. For those of you not aware, because of an issue with node_access permissions, for all intents and purposes OG did not work on Drupal 4.6 - specifically, if you had more than a few dozen active groups, the whole system would pretty much crap out.
Now I'm putting the finishing touches on a very large website/service using Drupal 4.7. We're seriously thinking of adding Organic Groups; and from what I understand, the node_access problem that plagued D4.6 has been fixed in 4.7 and onward. But my question is: will OG still scale now? Because of the specific circumstances, we have a reasonable expectation of accomodating huge traffic at some point. I understand the basic principle of why the node_access problem contributed to OG's demise on 4.6; but even assuming the problem is fixed, are there any more issues with Organic Groups scaling to large traffic? Anyone who has had experience with OG and substantial traffic, please state your experience. My thanks in advance --
I am not aware of the
I am not aware of the problem you are talking about, but about scaling you may want to check http://groups.drupal.org (OG based) which has been up for several months with 350 groups and 22,000 subscribers.
And that brings up a good point
Drupal broke their groups off onto a separate site. We've thought of doing the same. The obvious reasons are easy balancing of server load: it's a separate site, so if traffic gets too big, you can just move it to a separate server - and you don't have to network them (the servers, that is).
Did Drupal do this for the simple solution above, or because they would have had the problem I originally brought up?
Possibly, I guess "keeping
Possibly, I guess "keeping it clean" could be an additional reason.
But what was the problem with the node_access table? OG still uses it. Do you mean interaction with other access control modules?
Yes...
I did mean interaction with other access control modules.
There was some improvement
There was some improvement there when the "node access arbitrator" module was integrated into core making the behavior at least more predictable, so that you can design for avoiding conflicts.
If I understand it correctly, access control modules have been provided with a way not to write directly to the node_access table but to let the core node module do that for them. The most important ones (OG, TAC and a few others) complied, and there is also a button for rebuilding all permissions if something goes wrong.
Anyway, the end result is that you still can't do anything you want, but at least you can predict the outcome of access control conflicts. Node access permissions are ORed, the one who permits wins, everyone who forbids loses. If you tag a private OG node with a category which TAC allows to some role, access is granted. If you want to avoid that you design for it -- for example you use OG node types to which you don't apply any taxonomy vocabularies, or you tag them but handle permissions for those categories cautiously.
Some have been working on ways to allow a module forbid access completely, but no tangible results yet.
The thread at
The thread at http://drupal.org/node/116578 discusses OG performance in some detail.
Interesting opinion. Is
Interesting opinion. Is there any other serious way to control node access if you need it?
I have also noticed in /admin/og/og, in the "Access control" section of the page, an "Enable" button where it says:
"Enable access control if you want to author any content that is restricted to group members. The button below will delete one record in your node_access table (if needed) and thus enable node permissions on your site."
I guess that deletes the row with realm = "all" and starts adding rows with its own access realm if you need it.