Michiel Meeuwissen wrote:
> Alban Hertroys wrote:
>>> For many updates to different nodes I would like to use database
>>> transactions and/or the currently unsupported 'bulk-update' (update where
>>> number
>>> in (... etc)) commands, but that is not the issue I'm addressing. I meant
>>> frequent changes on the same value, as may typically occur in
>>> counter-fields ('view count' fields?) in e.g. polls and fora.
>> It would be interesting to see how many visitors/s you need to start
>> seeing the benefit of queing the counter values.
>
> Yes. But the whole thing grew from my dogma that a normal hit on a normal
> page should never result in any query in the database, and that any shift
> of load from the database from the app-server is a good idea, because
> app-servers are easier to load-balance (well, I don't know yet excactly
> what could go wrong with my delayed-stuff when load-balanced either...).
Easier to load balance... How so? You connect multiple app-servers to
the same database? That would hardly reduce the load on the server, it
may even increase the load on the database server. IMHO that would only
work if the database server isn't the bottleneck, in which case reducing
update statements wouldn't improve much at all.
Maybe I don't quite see what you mean.
> This was primarly meant as a kind of experiment on what would be possible
> to create a sort of cache for updates too. In most cases it is a bit
> senseless, because nodes don't generally change very often, and if they do
> you can as well execute it immediately, because it must happen any
> way. But I felt that this case was different.
And what about concurrent (simultaneous) updates from different
connections? You'd have to lock the record somehow if you cache updates
from within your app-server (or synchronize access to the cache).
Otherwise you may end up updating the record to the wrong value.
Of course this is of no concern for poll counters, they don't have to be
very accurate, but I'm certain it would hurt other applications of this
feature.
OTOH, if you let the database server handle the updates, it will handle
the locking (usually with less intrusive locks) for you. That usually
means that you can handle more updates/s. I think the net effect of a
(synchronized - IMO you really need to) update cache would be a
performance decrease.
<rant>
As an anology, MySQL used to do table locks on updates, which caused
trouble on sites with forums and such where people tend to do a lot of
concurrent updates to the same tables. I don't know if they changed that
in recent versions, ppl probably solved the problem with database
replication (very much for the wrong reason).
</rant>
> Michiel
>
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
