Daniel Albuschat wrote:
I'm currently widely adopting the usage of events to realize a live update on all clients when data has been changed from another client. Does anybody have experience with posting and registering for a lot of events and it's impacts?
The current usage of event is one posted event every few seconds, with at least one to five clients listening for that event. That's not much and I am planning to add much more "event-traffic", but I've noticed that fbserver utilized the CPU to 100% today and yesterday and I'm not sure, why. Are events something meant to be used rarely, or is something like 10 posted events per second with 100 different clients listening to potentially hundreds of events per connection feasible? Could it potentially slow down the server because of difficulties regarding transaction isolation?
Any hint, suggestion or experience would be highly appreciated.
Alan McDonald answers:
Your 100% CPU usage may have nothing to do with event traffic or responding with query refreshing. It may be a sweep - this is another whole story. If you use events, try to keep the responding query refreshes small. Row level invalidation is good if you can do it. You may go thru a period of adding a lot of events, but when you're finished you may realise that most of the events are making the clients respond in the same way each time. So fewer events do the same job. And yes,, many events causing clients to do a lot of stuff when really they shouldn't be doing them means a lot of network traffic for no particular gain.
Milan Babuskov answers:
I'm using events a lot in my applications (using Firebird 2.0 and 2.1). However, I have two "patterns" that make it work really fast:
For some events, each client has its own event name. The idea is that not all clients are interested in the same thing. So client applications have unique event names, and they get notified only when record is interesting to them.
In other uses (a lot of clients interested in the same event) I add a special field in database tables (last_update). The trigger updates LAST_UPDATE column before event is fired and clients just query WHERE LAST_UPDATE > :last_time_client_responded_to_event. There is DESC index on LAST_UPDATE so this works really fast even when tables are big an there are a lot of clients.
Jerry Sands answers:
I make heavy use of events. I have a Point of Sale system that uses events to alert other POS stations of changes in invoices, etc. The events also trigger the program that caused the event to refresh its datasets as well. I am actually using a dynamic event so to speak. The event name ends in an invoice number so any stations with the same invoice number open would get change events and keep themselves refreshed with the latest changes. It all works very well, overhead has never been any problem. I am using IBObjects which handle events very well. My understanding is other access tools had problems with event handling in the past and I don’t know if those problems are resolved or not. I have used these events from a single program connected to 20 + databases in a wide area network. There are some things I did not use events on before I started using IBObjects that I will eventually re-write to use them.