Subject | Re: [IBO] Events Limit - Network Traffic - CPU Cost |
---|---|
Author | Helen Borrie |
Post date | 2004-09-29T13:19:14Z |
At 02:22 PM 29/09/2004 +0100, you wrote:
TIB_Events. (You can add as many TIB_Events objects as you need).
small. I wouldn't suggest going crazy with them. Use them freely where
they are necessary; don't use them if they don't help anything.
connection. The server opens an alternative port to broadcast events
traffic. You might encounter firewall problems - ask on firebird-support
if so. And naturally you are going have bursts of traffic around the
network when commits occur to I/U/D operations that post events from
triggers or when work from SPs that post events gets committed.
Don't connect a local client using the ipserver protocol if it is going to
listen for events.
is really quite dumb.
There might be some impact on memory usage if the server is short of RAM or
starved by an overly-large page-cache. The memory table on which the Event
Manager operates could get quite large (comparatively) if there are large
numbers of users listening for a lot of events AFAIR, each record in the
events table uses about 105 bytes of RAM. Low RAM isn't propitious for
performance in any case, so you would be likely to notice the impact of
"event overload" under such conditions.
Helen
>FB 1.5.1, IBO 4No limit; but up to 16 events can be registered simultaneously in a single
>
>I am experiencing with FB Events and I have a couple of questions.
>
>
>1) How many Events can I fire in my application? Is there a limit in FB ?
TIB_Events. (You can add as many TIB_Events objects as you need).
>2) Is better to limit the use of Events in a large application with manyThere is some minor overhead with the event mechanism but it's very
>tables and many users or I can use them without problems ?
small. I wouldn't suggest going crazy with them. Use them freely where
they are necessary; don't use them if they don't help anything.
>3) Which problems can I experience ? An increase on Network TrafficYes; however, events traffic doesn't interfere with your data
connection. The server opens an alternative port to broadcast events
traffic. You might encounter firewall problems - ask on firebird-support
if so. And naturally you are going have bursts of traffic around the
network when commits occur to I/U/D operations that post events from
triggers or when work from SPs that post events gets committed.
Don't connect a local client using the ipserver protocol if it is going to
listen for events.
> and/or CPU work ?Not noticeably. The Asynchronous trap routine is tiny. The Event Manager
is really quite dumb.
There might be some impact on memory usage if the server is short of RAM or
starved by an overly-large page-cache. The memory table on which the Event
Manager operates could get quite large (comparatively) if there are large
numbers of users listening for a lot of events AFAIR, each record in the
events table uses about 105 bytes of RAM. Low RAM isn't propitious for
performance in any case, so you would be likely to notice the impact of
"event overload" under such conditions.
Helen