mspencewasunavailable wrote:

> --- In firebird-support@yahoogroups.com, Alexandre Benson Smith
> <iblist@...> wrote:
>
>> javaguru_uk wrote:
>>
>>> --- In firebird-support@yahoogroups.com, Alexandre Benson Smith
>>> <iblist@> wrote:
>>>
>>> Alexandre> What scale ?
>>> Alexandre> Provide some expected numbers.
>>>
>>> They also process between 100 and 200 daily transactions, which
>>> include false alarms as well.
>>>
>>>
>> pretty low...
>>
>> FB hanldes it with the hands tied at the back :-)
>>
>> see you !
>>
>> --
>> Alexandre Benson Smith
>> Development
>> THOR Software e Comercial Ltda
>> Santo Andre - Sao Paulo - Brazil
>> www.thorsoftware.com.br
>>
>>
>
> But over what time period and with what distribution? 700 users x
> 200 transactions = 140,000 per day. If the distribution's flat over
> 24 hours, then thats 1.6 /second and that's not so bad.
>
> But if they clump together in a suboptimal way (e.g., a bell curve
> with 40% of the total in one hour as a peak -- a distribution I've
> had to deal with in a past life) then that's around 15/second at the
> peak time.
>
> Michael D. Spence
> Mockingbird Data Systems, Inc.
>
>

Of course... But with so few details the only thing I could do is simple
calculations... :-)

But I think in a 24x7 environment like emergency call centers the events
*tend* to be flat, of course not a flat line, but with low pikes, at
least I think it is like that.

Everything depends in a lot more details than we have so far.. if each
event needs identify the most close unit, do a route calculation to the
destination poit, taking into account the traffic flow at that time, the
1.6 seconds is to few to get it (for 700 concurrent users) without
horizontal scaling, but if it is just a log system, do a simple insert
in 1.6 seconds is more than sufficient :-) But as we know, the real
world is not that black or white, instead it has a lot of shades of grays.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br