| Subject | Re: Intel Core 2 |
|---|---|
| Author | Adam |
| Post date | 2006-11-23T23:24:50Z |
--- In firebird-support@yahoogroups.com, "Anderson Farias"
<peixedragao@...> wrote:
creating new connections in terms of speed and RAM and also requires
more Disk I/O when the clients run similar queries (because of the cache).
One of the gotchas is the os scheduler (not scheduled tasks) now sees
each Firebird connection as a seperate task, and so the quantum
allocated to Firebird will be greater than for SS. Depending on what
else is on the same server, that may inadvertantly reduce the relative
quantum for other programs. It also means your database gets more
time, which can lead to better performance. But because you miss out
on the shared cache, there will be occasions where you need to read an
index from disk, an index that would have been in memory under SS.
CS works better when it encounters a corrupt database. If SS
encounters such a database, the service restarts which affects
connections to all databases. With CS, only the connection that
encountered the corruption is broken, and 1 phone call is preferable
to 50. For that reason alone, I would recommend CS when multiple
databases are involved.
If you are running big slow queries, you will suffer performance
problems under SS. If your queries tend to be relatively small, SS
will perform better in many cases.
There are benefits and downsides to both models. The key isn't to
become a 'fanboy' of one over the other, but rather to choose the most
appropriate one for the way the database will be used and the
capabilities of the hardware.
Adam
<peixedragao@...> wrote:
>Again it depends on your mix. CS incurs a larger overhead when
> My experience is that CS works *a lot better* than SS on SMP machines
> (with my apps in particular).
>
> We have an app (kind of a small ERP), 1Gb DB and at least 200
> concurrent connections (reporting/updates) with FB running on a
> Windows 2003 with 4 Xeon processors. We tryed 1st SS (our usual
> install) 'tied' to 1 processor and than moved to CS wich performed *a
> lot* better.
>
> Even with smaller apps (few records (200MB db) and with about 10 to 20
> concurrent users only) we have experienced better performances using
> CS over SS on machines with 2 or 4 processors.
>
creating new connections in terms of speed and RAM and also requires
more Disk I/O when the clients run similar queries (because of the cache).
One of the gotchas is the os scheduler (not scheduled tasks) now sees
each Firebird connection as a seperate task, and so the quantum
allocated to Firebird will be greater than for SS. Depending on what
else is on the same server, that may inadvertantly reduce the relative
quantum for other programs. It also means your database gets more
time, which can lead to better performance. But because you miss out
on the shared cache, there will be occasions where you need to read an
index from disk, an index that would have been in memory under SS.
CS works better when it encounters a corrupt database. If SS
encounters such a database, the service restarts which affects
connections to all databases. With CS, only the connection that
encountered the corruption is broken, and 1 phone call is preferable
to 50. For that reason alone, I would recommend CS when multiple
databases are involved.
If you are running big slow queries, you will suffer performance
problems under SS. If your queries tend to be relatively small, SS
will perform better in many cases.
There are benefits and downsides to both models. The key isn't to
become a 'fanboy' of one over the other, but rather to choose the most
appropriate one for the way the database will be used and the
capabilities of the hardware.
Adam