--- In firebird-support@yahoogroups.com, Milan Babuskov <milanb@...>
wrote:

>
> myles@... wrote:
> > After thinking this through, I'm considering that we could have

thousands of

> > separate Firebird databases running on multiple separate servers,

to handle

> > this request. Any individual server will probably have 100+

databases on

> > it. I understand that each server runs a single security database

for user

> > accounts, etc.
>
> Make sure that access to Firebird is only possible via your web app.

and

> it should be fine.
>
> > but other than this consolidation, are there any issues I
> > should be concerned about with this architecture that others have
> > encountered?
>
> Server RAM (memory). If you're going to have 100+ databases in use,
> you're probably going to have 100+ attachments, so it's all question of
> number of concurrent users per database. You should also weight whether
> to go with SuperServer or Classic. If not many databases are going

to be

> used at once, but by many users, then SS might be a much better choice.
>
> You might also consider to have some machines dedicated to Firebird and
> others to Apache/PHP. Just find the right ratio (one Apache/PHP server
> per 30 Firebird servers, for example). It would also make

administration

> simpler, as you would have the application in single place.
>

SS may have a problem when supporting connections to that many
databases with the 2GB of addressable RAM per process (32 bit). We
have seen problems with around 30 databases (although more than a
single connection per database). If you experience this, then CS would
be the better solution providing you have enough RAM to support 100
connections (on Windows I find it is usually 7 - 10MB each + whatever
sorting in RAM it needs to do, don't know on Linux.)

Adam