Resolving Performance Problems 
Author Message
 Resolving Performance Problems

Help!!! I think I might need to do some BDE performance tuning. Or maybe
I just need an exorcist... (I posted this messages on
borland.public.delphi.database.desktop, but nobody has answered!)

My users are experiencing some serious performance problems with my app.
The problem is an intermittent slowdown, in which it may take several
seconds for the user to scroll to a new record. While one user's
performance is suffering, the other users may be flying.

The app is written in D3, using BDE 4.51 and Paradox tables. They're
running Win95 with Pentium 180's with 32-64mb ram, across a Novell 3.12
network. (Some users are using the Netware IntraNet client, others are
using the Microsoft client for Netware networks, and there appears to be
no performance difference with the different clients.) There are
generally 10-15 users using the tables at any given time, and a couple of

them are using Paradox for DOS against the same tables. The largest table

is a very wide table about 3mb in size, with a 3-field primary index
about 24k in size. A network analyzer has reported many very small packet

sizes going across the network while our app is running.

Some time ago, I raised the MAXBUFSIZE in the BDE settings to 8192, which

appeared to help somewhat, but didn't solve the problem completely.  Is
there any other performance tuning I can do to the BDE that might
increase the packet size (and perhaps reduce the number of packets), or
speed up access to the shared tables in some other way?

Any other suggestions about what I could investigate that might be
causing this, in Delphi, the BDE or something about the network itself
would be helpful.

TIA....

Maggie Owens;
--
Autoreplys will (hopefully) bounce. Remove the "invalid." from my address
to reply.



Wed, 18 Jun 1902 08:00:00 GMT  
 Resolving Performance Problems

Quote:

> Help!!! I think I might need to do some BDE performance tuning. Or maybe
> I just need an exorcist... (I posted this messages on
> borland.public.delphi.database.desktop, but nobody has answered!)

No clear answers from here either, just some suggestions to check. But
sometimes someone else may get the right new idea, after seeing some
insignificant sentences:)

Is it so, that the slow down happens only on some of the workstations, and
on some other workstations never? If this is the case, it could also be
a HW problem, erratic network adapter or cabling.

Also, have you done the usual checks:
 -Turn off all the virus checking programs
 -Turn off all the screen savers from the server (especially NT server)
 -Turn off all the MS-Office (Word) style automatic indexing systems etc.,
  that may be running on the background.

Could some user have wrong PrivateDir setting, pointing somewhere to
the server's hard disk? How about those DOS users, and their settings?

Quote:
> is a very wide table about 3mb in size, with a 3-field primary index
> about 24k in size. A network analyzer has reported many very small packet

I have not used 3-field primary indexes, but your guess may be right, in here
there could be something. Keeping indexes up to date usually always causes
small packets sent via network. Is it possible to test the app with some other,
more simple index setting?
I also try to keep the number of maintained indexes so low as possible, of
course still keeping the useful, practical level.

---
I wonder if anyone has not made a Paradox DB testing and tuning utility. For
starters it could just monitor the physical I/O on every table and index
files, and show one day's results on screen graphically.
In NT there possibly is this kind of system tool, I'm not sure.

Markku Nevalainen



Wed, 18 Jun 1902 08:00:00 GMT  
 Resolving Performance Problems

Mark,
I come in here part way through this thread, so don't know the nature of your
problem. I understadn that you are experiencing slow responses over a network with
a Delphi app. You say you are using Paradox tables and that the database is large.
I would suggest that this is a place to start loking. Whenvever you do anything of
this nature, you load the network tremendously as all processing of the database is
done on the client. If you convert to something like MS SQL 6.5 or Oracle for
example, you will see improvements as all processing takes place on the server.
Paradox talbes (and, for that matter .DBF tables) are not really designed for
networked apps.

Quote:


> > Help!!! I think I might need to do some BDE performance tuning. Or maybe
> > I just need an exorcist... (I posted this messages on
> > borland.public.delphi.database.desktop, but nobody has answered!)

> No clear answers from here either, just some suggestions to check. But
> sometimes someone else may get the right new idea, after seeing some
> insignificant sentences:)

> Is it so, that the slow down happens only on some of the workstations, and
> on some other workstations never? If this is the case, it could also be
> a HW problem, erratic network adapter or cabling.

> Also, have you done the usual checks:
>  -Turn off all the virus checking programs
>  -Turn off all the screen savers from the server (especially NT server)
>  -Turn off all the MS-Office (Word) style automatic indexing systems etc.,
>   that may be running on the background.

> Could some user have wrong PrivateDir setting, pointing somewhere to
> the server's hard disk? How about those DOS users, and their settings?

> > is a very wide table about 3mb in size, with a 3-field primary index
> > about 24k in size. A network analyzer has reported many very small packet

> I have not used 3-field primary indexes, but your guess may be right, in here
> there could be something. Keeping indexes up to date usually always causes
> small packets sent via network. Is it possible to test the app with some other,
> more simple index setting?
> I also try to keep the number of maintained indexes so low as possible, of
> course still keeping the useful, practical level.

> ---
> I wonder if anyone has not made a Paradox DB testing and tuning utility. For
> starters it could just monitor the physical I/O on every table and index
> files, and show one day's results on screen graphically.
> In NT there possibly is this kind of system tool, I'm not sure.

> Markku Nevalainen



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Access Violation with TQuery as both Master/Detail: problem resolved

2. DNS problem at JUMBO will be resolved ASAP

3. JUMBO resolves DNS problem

4. Performance problems with Delphi & Sybase System 11

5. Application Performance Problem

6. Performance problem

7. Borland Bug and performance problem

8. Lan Network overload performance problem using ODBC

9. Performance problems with Access

10. Performance Problem with D2 and MSAccess ODBC

11. DBGrid+calculated fields performance problem

12. Paradox/Novell performance problems?

 

 
Powered by phpBB® Forum Software