--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> Adam wrote:
>
> > Apart from the firewall problems you may encounter, another

important

> > thing you need to remember is that there is a large potential to
> > overwhelm your server. If you have lots of clients waiting for the
> > same event, and those clients all immediately request a lot of

data

> > when that particular event fires, you can get into trouble.
>
> That's true, but having the same large number of clients polling for
> new data means you're overwhelmed even when nothing is happening.
>

Overwhelming obviously depends on the number of clients and frequency
of polling, as well as the complexity of determining whether changes
occur. Events are more efficient in this manner, because they only
fire when something interesting occurs (if you are doing the right
thing in your triggers).

Generally speaking, a polling process with a realistic interval which
is started by different people at arbitrary times will tend to
distribute the load. Whether this is workable depends on the business
requirements. For us, it is not a problem if an updated piece of data
takes 15 minutes to find its way to all the nodes.

An event driven process that automatically calls a download will
ensure that all nodes phone home within a very short space of time.
This can be mitigated in at least two ways, one automatic and one
manual. The automatic way is to use a random wait. When a node
receives an event notification, it waits a random length of time
(uniform dist) before attempting to synchronise. Providing the
maximum possible length of time is 'long enough', this should see a
nice distribution of load. The manual way is great if you are
refreshing a UI. Rather than firing a request immediately, just flash
an icon in the tool bar that says something like, updates available,
click to synchronise.

Adam