javaguru_uk wrote:

> --- In firebird-support@yahoogroups.com, Alexandre Benson Smith
> <iblist@...> wrote:
>
> Alexandre> 10000 to 20000 for all users right ?
> Alexandre> It's still low...
>
> Alexandre> 20000 / 24 / 60 = 13 tpm
>
> Well, the whole system is much more complicated than that and it has
> much higher requirements. We are talking of a nationwide project, so
> we may be looking at 20,0000+ concurrent users when we set it all up,
> which will, obviously, increase the number of daily transactions
> considerably. The figures I provided are only for the CAD system. I
> haven't included the Records Management System, which will store more
> data based on the incident reports. These figures are for a pilot we
> are about to implement.
>
> My question is not about numbers per se, it is about a workflow for
> these kind of systems using firebird. We are going to use datamarts
> and datawarehouses. The system doesn't just store the data. The data
> is used for later analysis.
>
> So, is there anyone with experience in very large databases using
> Firebird, and what was the workflow used? What tools have you used?
> Did you create your own tools for ETL?
>
> Thanks in advance,
>
> Fidel.
>
>

My answers were as simple as your questions :-)

What I intend with my answers was to get more info about your project.

Maybe this message could be of help...

-- begin of original message
-------- Original Message --------
Subject: Re: [firebird-support] Are there any scalability guidelines
published for Firebird?
Date: Thu, 3 Feb 2005 10:01:24 -0500
From: Dalton Calford <dcalford@...>
Reply-To: firebird-support@yahoogroups.com
To: firebird-support@yahoogroups.com
References: <1107314863.15247.38.camel@...>



Hi David

What are you looking for?
If you are asking, what the limits are, and what platforms does FB support,
then that is easy to answer, but, all things are limited by the final design
of the database metadata.

You need to understand the needs of the design, then determine how those needs
are met by the software and hardware, then you must decide if the
implementation will scale to a larger needs environment without a redesign.

This is a very detailed area of design.

We have firebird processing customer calls (over 2 million phone calls a day)
in a 5 9's environment. That system is replicated in three different cities
across two provinces. A different Firebird system performs billing
functions - a very detailed process that bills based upon duration and time
of call, also centred around location called from, called to and what
services apply at the time of call for that particular customer. If you
consider the call volume, this should give you an idea as to the capabilities
of the system.
The billing database also serves the IVR(Interactive Voice Response) units
which allow a customer to dial a number to check thier current call usage and
minutes remaining. The IVR system has to query the database and respond in
under 2 seconds - impressive given the volume of data.
Our CSR's (customer service reps) link into another database that processes
orders, hookups, disconnects, and all other customer related issues.
For backup and other considerations, we have multiple history databases, that
allow us to generate a historic invoice for the past 6 years. This is used
by the CSR's to view customer calling paterns and build services better
suited to our clients (also it is required by law....)
Our web page is dynamically generated by php and firebird.
Our lines database controlling all the routers, fibre, servers etc is also
used by Firebird and is accessed by custom software on Sharp Zaurus PDA's.

So, can Firebird scale, yes.
Can any Database scale - if properly designed to handle the shortcommings of
the environment, yes.
Does Firebird ease the design burdon of developing a scalable environment -
very much so.

Please, if you need specific help, ask, overall generalities do nothing but
satify the needs of a marketing dept.

best regards

Dalton Calford

On February 1, 2005 10:27 pm, David Johnson wrote:
> I understand (too well!) that "scalability" is a fuzzy concept. But,
> each of the factors that are used to define the concept in different
> areas can be expressed clearly and distinctly. It should be possible to
> develop some guidelines as starting points for scaling hardware and
> configurations for Firebird based on the application, the user base, and
> the environment.
>
> Is there a already published configuration guideline that addresses
> Firebird hardware and software scaling for different purposes? I expect
> that when I finally get Helen's book, it will have some of this
> information.
>
> For example, I am mostly concerned with large real-time systems (TB)
> with a large and busy concurrent user base (1,000 to 8,000 users).
> However, I also work with standalone desktop apps and even occasionally
> with handheld applications. What I like about Firebird is that it is
> conceptually possible to run the same datastore on all of my platforms.
>
> It is easy to find information on the mailing list and Google for
> configurations from 1 to 100 user connections, or small web-server
> applications with connection pools of up to 100 concurrent connections.
> Third party products such as C-JDBC allow clustering for databases that
> run primarily "read" operations, such as web sites, but cannot compete
> with a larger centralized store for enterprise scale real-time
> monitoring applications.
>
> The down-scaled applications (hand held devices) and the up-scaled
> applications (centralized real-time monitoring, recording and management
> of all of a fortune 500 company's fixed and mobile resources) are
> tougher to find information on.
>
> If there is not already such a document, I would like to propose that we
> make one that addresses hardware and software configuration for scales
> something like these:
>
> 1. mini - embedded hand held device and PLC applications
>
> 2. desktop - embedded desktop applications
>
> 3. tiny - 1 to 10 clients talking to a shared server, or a web
> application that requires 1 to 10 pooled connections
>
> 4. small - 10 to 100 clients talking to a shared server, or a web
> application that requires 1 to 100 pooled connections
>
> 5. medium - 100 to 1000 clients talking to a shared server, or a web
> application that requires 1 to 1000 pooled connections
>
> 6. enterprise - 1000 and up clients talking to a shared server, or a web
> application that requires 1000 and up pooled connections
>
> Allowance must be made in the guidelines for the type of work being
> performed on the server, and clustering options should also be
> addressed.
>
> For example, a web application is typically read intensive by has low
> write to read ratio, so clustering several smaller machines with a third
> party product such as C-JDBC may be a better choice from both a cost and
> performance perspective than a single large box.
>
> A counter example is a large centralized real-time asset monitoring and
> management tool for a fortune 500 company, where nearly 50% of the
> transactions involve writes. In this case, clustering actually harms
> performance, and a much larger box is desirable.
>
> Related to scalability and clustering, I read that Firebird's
> predecessor was actually built to run on a VAX cluster. Is that code
> still in place, will it run on modern Windows and linux systems, and
> does it provide any benefit in today's world?
>

-- end of original message

hth

see you !

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