Michiel Meeuwissen wrote:
> Nico Klasens wrote:
>> It sounds a wierd hack to me.
>>
>> Why would a delayed update be 10 times faster than a normal update? I
>> would have expected it to be a little less. It can't be the database
>> overhead so it must be code in MMbase. My guess is the eventsystem and
>> cache updates.
>
> I mean that if you change a field a very often, that it may
> be enough to write it to the database only once per 10 seconds. Especially
> if it is no big deal if a few updates are lost, if in those 10 seconds the
> system happens to crash or so.
If I understand correctly, you want to queue up concurrent updates and
only store the latest value of a field instead of updating it each time.
Looks like you're trying to implement "command queueing".
A time interval seems relatively complicated, and may result in rather
long queues on fast(er) servers. It may cause problems with the servers
of next year...
Looks like a feature that could be useful on records with high update
frequencies. 10 seconds seems excessive, though - a number specified in
milliseconds is more appropriate IMO.
>> And yes, a change on the StorageManager should mean an update on the
>> database. It is called a 'storage layer' for a reason :)
>
> I mean: if I can predict that nothing will really change, should it still
> happen then? If i know that in the database is '1234' and I get the
> instruction to update that to '1234', can I be so free to do nothing at
> all? It is possible that in some situations that would give issues, but I
> don't see it yet.
Do you _know_ that nothing changes in the database? It is easy to check
that nothing changed between the first and last queued values, but that
could still be different from what's stored.
OTOH, Checking a (the first?) queued value with what's in the database
requires a lookup, which is also required once you perform an update to
store the last queued value - I don't see the benefit in doing that. A
database lookup is required in either case.
>> IOW, it is a quick fix for a more fundamental problem or it can be
>> achieved by already existing code.
If I understand correctly what problem Michiel tries to solve, I don't
think that's the case.
> You may be right, but you didn't really convince me. The more fundamental
> problem is I think 'mmbase persists everything to the database immediately,
> while that in some cases it not worth the overhead'. Since I cannot think
> of a generic algorithm to determin in which cases some update-collecting
> can be acceptable, I thought that simply indicating it like I proposed with
> these 'processors', would not be so wrong.
>
> Btw, I don't foresee that the poll I just implemented, will actually be
> that much visited that something like this is essential, so for the moment
> it is rather academic to me, but I can imagine situations where it is
> important to spare the database a bit like this.
Hehe... That'd be some poll...
> 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.
--
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
