| Subject | RE: [firebird-support] Need Feedback on Using Firebird for Element Management Software |
|---|---|
| Author | David Johnson |
| Post date | 2005-03-22T01:59:02Z |
On Mon, 2005-03-21 at 16:56 -0800, Nina Grooms wrote:
whether it is chatty enough to warrant putting the app on the same
server as the database in your case. Local connection is slightly
faster, I believe.
On a multi processor or simulated multi processor system (hyperthreaded)
you will want to use the "classic" model. On a true single server
system you may want to check out super-server.
Once it becomes mainstream, the Vulcan rewrite should offer huge
improvements for your purposes.
transactions is, from the math I have seen, not a likely scenario to
actually support. Your java app would choke on 1,000 concurrent threads
on this hardware, even if the DBMS could support that high of a spike
load. However, 1,000 transactions per second is quite achievable with
this hardware and good database design, even on a single thread.
I would probably crank up the RAM on the boxes if I had the option.
It would be well worth your while to track down the rest of the postings
on my February thread that Dennis Mulder referenced, and the links that
Dalton directed me to in his other postings.
> >Firebird's wire protocol is relatively chatty - you will need to test
> 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.
>
whether it is chatty enough to warrant putting the app on the same
server as the database in your case. Local connection is slightly
faster, I believe.
On a multi processor or simulated multi processor system (hyperthreaded)
you will want to use the "classic" model. On a true single server
system you may want to check out super-server.
Once it becomes mainstream, the Vulcan rewrite should offer huge
improvements for your purposes.
>Each connection is resource intensive. 1,000 truly concurrent
>
> How much concurrency does you app support (i.e. how many concurrent
> transactions can be expected)?
>
>
>
> 1000 concurrent transactions worse case.
>
>
transactions is, from the math I have seen, not a likely scenario to
actually support. Your java app would choke on 1,000 concurrent threads
on this hardware, even if the DBMS could support that high of a spike
load. However, 1,000 transactions per second is quite achievable with
this hardware and good database design, even on a single thread.
I would probably crank up the RAM on the boxes if I had the option.
It would be well worth your while to track down the rest of the postings
on my February thread that Dennis Mulder referenced, and the links that
Dalton directed me to in his other postings.