Subject | Re: [firebird-support] Re: Active transactions (benchmark results - updated) |
---|---|
Author | Valdir Marcos |
Post date | 2005-10-19T04:27:51Z |
You are right and I really appreciate FB preserving a place for very small companies in it.
This range of servers' quality is excellent because I have 'servers' (win [98, 2K, XP, 2003]) from Ultra Slim through Normal serving just one (itself) up to 100 workstations, with excellent performance in all cases.
I just have big problems on Win 2003 Server Standard Edition.
Yours,
Valdir Marcos
Sao Paulo-SP-Brazil
www.homeostase.com.br
This range of servers' quality is excellent because I have 'servers' (win [98, 2K, XP, 2003]) from Ultra Slim through Normal serving just one (itself) up to 100 workstations, with excellent performance in all cases.
I just have big problems on Win 2003 Server Standard Edition.
Yours,
Valdir Marcos
Sao Paulo-SP-Brazil
www.homeostase.com.br
----- Original Message -----
From: Adam
To: firebird-support@yahoogroups.com
Sent: Tuesday, October 18, 2005 9:11 PM
Subject: [firebird-support] Re: Active transactions (benchmark results - updated)
--- In firebird-support@yahoogroups.com, "Valdir Marcos"
<valdir.marcos@s...> wrote:
>
> I agree 100% on part 1 below, it's the main point where FB is more
intelligent and smart than any other RDBMS, but on part 2, could I
ask a doubt?
> For those like me, who have very small companies as clients, which
have old and resourceless computers as the FB server. And FB does an
excellent job on these old computer where no other RDBMS would
install... My question is if Part 2 become true, will FB require a
large quantity of memory like its competitors?
Memory and performance is a trade off. If firebird was allowed a
larger lock table size and a wider hash table, then it could
potentially perform better. Of course this would mean it would
consume more resources, but back when the decision was made to use
those particular values, memory was measured in KB, possibly a few
MB. But this is 2005, many desktops ship with multiple GB of RAM, and
servers are even higher.
I am sure in a few years time, you could look back on whatever you
select today and suggest that the figures we come up with were fine
when computers only had 1 or 2 GB of RAM, but now the average mobile
phone has 500GB if internal storage, it makes more sense to optimise
it for multiple TB of memory.
But to answer your question, Firebird needs to perform well out of
the box. I think if you are digging out a PII as a Firebird server,
then you should reserve yourself to the fact that you may have to
reduce some of the settings, but I imagine if you did reduce these
values to what they are today, you will get a very similar if not
identical performance to what you get today.
Perhaps there is some scope for a bunch of different possible default
values.
Ultra Slim -> Early Pentiums, up to 32 MB RAM
Low Spec -> P2 - P3, up to 128MB RAM
Normal -> P4, up to 1GB RAM
Fast -> P4+, up to 4GB RAM
Huge -> 4GB +
The installer could grade the system and suggest the default profile
of the system, and if you agreed with its conclusion, it would
install that particular firebird.conf. And yes, these figures are
already out of date, but you get the gist.
Adam
>
> Yours,
>
> Valdir Marcos
> www.homeostase.com.br
>
>
> ----- Original Message -----
> From: Alexandre Benson Smith
> To: firebird-support@yahoogroups.com
> Sent: Tuesday, October 18, 2005 2:35 PM
> Subject: Re: [firebird-support] Re: Active transactions
(benchmark results - updated)
>
>
> Ann W. Harrison wrote:
>
> Part 1 = A significant project goal is to minimize the number of
tuning
> >parameters by thinking about the problems they're meant to
address and
> >designing the system to handle those problems rather than
dropping them
> >on the unfortunate dba.
>
> Part 2 = And we should increase the default lock table
> >size and the default hash table width - those were designed for
> >computers of the 1980's, where every byte of memory counted.
Sigh.
> >
> >
> And besides what could be improved I think FB does a really good
job on
> this point.
>
> >Regards,
> >
> >
> >Ann
> >
> >
> see you !
>
[Non-text portions of this message have been removed]