Hi there, I'm pretty green when it comes to Drupal, so forgive me any ignorance.
I think that it all depends on who is doing the 'looking', if the majority of your users are not logged in then they could go to any one of the slaves and it would never matter what they see, if it's outdated it won't be by much (and most of the times that content could come straight from the cache anyway since anonymous users are all the same user so they will see exactly the same content), a user that refreshes a page and is not himself/herself the cause of an update has no way of knowing if a page really is the last version or 1 or 2 seconds out of date, as long as the page is consistent they'll be happy. (When stuff starts breaking that's a different matter of course.)
As soon as someone logs in the situation changes dramatically because these are the users that have update rights (unless of course you allow your anonymous users to update content, in which case a warning message that their update will show up shortly should be provided, and which is fairly common on high volume sites.)
So, as long as the anonymous / logged-in users division is reasonable you'll get a big payoff without any penalties. You'd have to put a figure on that ratio to be able to decide if the scenario if feasible.
Another possibility is to 'bind' the user to the machine that they land on, use a load distribution machine that passes through the complete HTTP request to the 'bound' node, update the bound node (which will give the user an immediate response and will always show consistent output) and the master, the master should take care of replicating to the other nodes. Sequence numbers would still have to be assigned centrally.
Another issue is sequence numbers.
I think I can see why Drupal uses sequence numbers in a separate table (portability ?) but that makes atomic inserts a lot harder and creates a headache during synchronization, possibly it would be better to document which dbms's/table types support auto_increment and to handle the ones that don't in single node configurations only.
Hi there, I'm pretty green when it comes to Drupal, so forgive me any ignorance.
I think that it all depends on who is doing the 'looking', if the majority of your users are not logged in then they could go to any one of the slaves and it would never matter what they see, if it's outdated it won't be by much (and most of the times that content could come straight from the cache anyway since anonymous users are all the same user so they will see exactly the same content), a user that refreshes a page and is not himself/herself the cause of an update has no way of knowing if a page really is the last version or 1 or 2 seconds out of date, as long as the page is consistent they'll be happy. (When stuff starts breaking that's a different matter of course.)
As soon as someone logs in the situation changes dramatically because these are the users that have update rights (unless of course you allow your anonymous users to update content, in which case a warning message that their update will show up shortly should be provided, and which is fairly common on high volume sites.)
So, as long as the anonymous / logged-in users division is reasonable you'll get a big payoff without any penalties. You'd have to put a figure on that ratio to be able to decide if the scenario if feasible.
Another possibility is to 'bind' the user to the machine that they land on, use a load distribution machine that passes through the complete HTTP request to the 'bound' node, update the bound node (which will give the user an immediate response and will always show consistent output) and the master, the master should take care of replicating to the other nodes. Sequence numbers would still have to be assigned centrally.
Another issue is sequence numbers.
I think I can see why Drupal uses sequence numbers in a separate table (portability ?) but that makes atomic inserts a lot harder and creates a headache during synchronization, possibly it would be better to document which dbms's/table types support auto_increment and to handle the ones that don't in single node configurations only.
Best regards,
Jacques Mattheij
December 13, 2007 - 19:12