| Subject | Re: [IBO] Pentium speed |
|---|---|
| Author | Paul Schmidt |
| Post date | 2001-02-20T17:51:12Z |
Wanadoo:
As far as databases are concerned, the usual complaint is a slow
application, in that the user presses a key, and it takes time before
a result comes back. This doesn't mean a server problem, it can be
any of about 6 different problems.
1) The server is too small for the job, this means the server wasn't
sized properly initially, or has seen an expanded role since put into
service.
2) The server is being asked to do too many things, is the db server,
also a web server, file/print server, email server, firewall and
internet gateway? This is common in Windows environments, where the
licence fees can outstrip the hardware costs. Often the best
solution, is a second machine to handle part of the load.
3) The server hasn't been properly configured, look at ibconfig,
maybe one of those settings needs to be different, copy the file and
then play with it a bit. You kept a copy, so if it gets worse, you
can restore it.
4) The database wasn't properly rebuilt for production, before a test
database goes into production, the meta-data only should be backed-up
and restored to build the production database. However, the number
of pages, and page size may need to be adjusted for the heavier
production loads.
5) The network has a problem, this could be heavy loads, or a cranky
piece of equipment (network card, hub, router or gateway), or
something mis-configured.
6) The application has a problem, often developers lget working code,
they don't always have the time to run an analysis on the database to
make sure all of the queries are as efficient as possible. The
queries may also not be as client/server friendly as they should be.
Developers often work as lone gunmen.
You may have one of the above problems, but it's not uncommon to have
more then one, or even all of them. The only one you have considered
is the first one. Often the computers get blamed, when the real
problem is that someone is driving a table sweep on a big table, when
reworking the query or adding an index would have it 100 times as
efficient.
As far as databases are concerned, the usual complaint is a slow
application, in that the user presses a key, and it takes time before
a result comes back. This doesn't mean a server problem, it can be
any of about 6 different problems.
1) The server is too small for the job, this means the server wasn't
sized properly initially, or has seen an expanded role since put into
service.
2) The server is being asked to do too many things, is the db server,
also a web server, file/print server, email server, firewall and
internet gateway? This is common in Windows environments, where the
licence fees can outstrip the hardware costs. Often the best
solution, is a second machine to handle part of the load.
3) The server hasn't been properly configured, look at ibconfig,
maybe one of those settings needs to be different, copy the file and
then play with it a bit. You kept a copy, so if it gets worse, you
can restore it.
4) The database wasn't properly rebuilt for production, before a test
database goes into production, the meta-data only should be backed-up
and restored to build the production database. However, the number
of pages, and page size may need to be adjusted for the heavier
production loads.
5) The network has a problem, this could be heavy loads, or a cranky
piece of equipment (network card, hub, router or gateway), or
something mis-configured.
6) The application has a problem, often developers lget working code,
they don't always have the time to run an analysis on the database to
make sure all of the queries are as efficient as possible. The
queries may also not be as client/server friendly as they should be.
Developers often work as lone gunmen.
You may have one of the above problems, but it's not uncommon to have
more then one, or even all of them. The only one you have considered
is the first one. Often the computers get blamed, when the real
problem is that someone is driving a table sweep on a big table, when
reworking the query or adding an index would have it 100 times as
efficient.
On 20 Feb 2001, at 2:33, Wanadoo wrote:
To: <IBObjects@yahoogroups.com>
From: "Wanadoo" <dmaya@...>
Date sent: Tue, 20 Feb 2001 02:33:42 +0100
Send reply to: IBObjects@yahoogroups.com
Subject: [IBO] Pentium speed
> Hello :
>
> I've a Pentium II - 128Mb. UltraWide SCSII II and now ( with +10 users
> ) it's too slow What is better, increase RAM memory, install a
> bi-processor computer, both things...
>
> Thank you very much
>
> David
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~> eGroups is now Yahoo! Groups Click here for
> more details http://click.egroups.com/1/11231/1/_/685810/_/982632765/
> ---------------------------------------------------------------------_
> ->
>
>
>
>
Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com