Subject | RE: [firebird-support] Need Feedback on Using Firebird for Element Management Software |
---|---|
Author | Nina Grooms |
Post date | 2005-03-22T00:56:57Z |
________________________________
From: David Johnson [mailto:d_johnson@...]
Sent: Monday, March 21, 2005 4:22 PM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] Need Feedback on Using Firebird for
Element Management Software
From: David Johnson [mailto:d_johnson@...]
Sent: Monday, March 21, 2005 4:22 PM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] Need Feedback on Using Firebird for
Element Management Software
On Mon, 2005-03-21 at 16:06 -0800, Nina Grooms wrote:
>
>
>
>
>
> ________________________________
>
> From: Helen Borrie [mailto:helebor@...]
> Sent: Monday, March 21, 2005 3:21 PM
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] Need Feedback on Using Firebird for
> Element Management Software
>
>
>
> At 09:51 PM 21/03/2005 +0000, you wrote:
>
>
>
> >Were planning on using Firebird v1.5.2 as the database for an
> >Element Management Software (EMS) product for a wireless LAN
> >product. We're trying to find out if anyone out there has used
> >Firebird successfully in this type of application. Specifically, we
> >will be managing many network elements that will require processing
> >a large amount of transactions and want to know if Firebird is well
> >suited for this. Does anyone out there have feedback for us on this?
>
> If you provide some specifics about the kinds of "elements" you want
to
> store and retrieve and what you consider a "transaction" to be, I'm
sure
>
> there will be some answers for you. Some general specifications
> regarding
> system architecture would enlighten. If you know the environment in
> which
> the software will be developed, that might throw up some leads for
you,
> too.
>
> ./heLen
>
>
>
>
>
> We're developing a network management product that will eventually
> manage in excess of 1000 network elements (routers, switches, etc.).
> We'll use the database to store configuration criteria, polling
> thresholds, alarms, events, etc. for each of the network elements.
>
>
>
> We consider a transaction to be a specific action on the database
> (retrieve, write, update and delete) that can be rolled back. We
expect
> that we will need to be able to accommodate in excess of 1000
> transactions/second.
>
...
> The software is being developed in a Linux development environment.
>
>
What class of hardware are you running the app on?
We're running the app on a server with either Pentium III or compatible
(ok to use for small number of network elements) or dual processor
Pentium III or compatible 1 GHz or better (large number of network
elements); 512 MB RAM (small number of network elements) or 2 GB RAM
(large number of network elements); 40 GB (Raid 1) SCSI U320/160 hard
disk. The application and database can run on the same server or
separate servers.
How much concurrency does you app support (i.e. how many concurrent
transactions can be expected)?
1000 concurrent transactions worse case.
Is a two-phase commit necessary (Conversely, does it matter if you lose
data under some circumstances)? MySQL, for example, does not support
two phase commit, whereas Firebird does. This gives MySQL a performance
edge in the benchmarks, but results in data loss in some circumstances.
> General database related specs: JDBC distributable, retrieval database
> architecture.
You will want the jaybird class 4 driver for firebird.
Firebird is a full-featured database comparable to any commercial
offering in terms of features and performance.
Thanks!
Nina
<http://us.adserver.yahoo.com/l?M=298184.6191685.7192823.3001176/D=group
s/S=:HM/A=2593423/rand=334015824>
________________________________
[Non-text portions of this message have been removed]