Board index » delphi » Slow paradox table access on network

Eric Grajales

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Slow paradox table access on network

I have a Delphi4 application that shares data on an
NT 4.0 Server.  The first client that accesses the data
is quick and responsive, when the second client accesses
the data, the response slows down 10 fold.  As more users
access the server the slower the system becomes.
The clients are running Win98.

We recently converted from a Novell Server that did not
have this problem.

Has anyone encountered this problem or have any suggestions.

Eric G.

 
Robb

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


Quote
Eric Grajales <er...@knight.simsol.com> wrote:
>I have a Delphi4 application that shares data on an
>NT 4.0 Server.  The first client that accesses the data
>is quick and responsive, when the second client accesses
>the data, the response slows down 10 fold.  As more users
>access the server the slower the system becomes.
>The clients are running Win98.

>We recently converted from a Novell Server that did not
>have this problem.

>Has anyone encountered this problem or have any suggestions.

>Eric G.

Eric,

I had a similar problem on a network I installed recently.

I was using NETBEUI & TCP/IP on all W/S and the server and found the
network was running like a sick dog. I have 100BaseT cards installed
everywhere and couldn't beleive the poor network responses. I got rid
of NETBEUI on the server and everyone was happy again.

Are you using MS NETBEUI on the server? if so, get rid of it and use
TCP/IP instead. and let NETBIOS do the windows networking over TCP.

Note: Microsoft suggest using NETBEUI for windows networking and it
may work OK if you're only using NETBEUI. From what I found, if you
add any other protocols, it seems to lose the plot.

Hope this helps,

Robbie...

Bruce Robert

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


How is the NT server configured? In my experience NT servers require much
more hardware to give the same performance shown by Netware.

Quote
"Eric Grajales" <er...@knight.simsol.com> wrote in message

news:yhLf4.27382$W2.382895@iad-read.news.verio.net...
Quote
> I have a Delphi4 application that shares data on an
> NT 4.0 Server.  The first client that accesses the data
> is quick and responsive, when the second client accesses
> the data, the response slows down 10 fold.  As more users
> access the server the slower the system becomes.
> The clients are running Win98.

> We recently converted from a Novell Server that did not
> have this problem.

> Has anyone encountered this problem or have any suggestions.

> Eric G.

Sundial Service

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


Following up on Robbie's point, I think the jury is still out as to just
how much of an impact the NETBEUI protocol is having on the slew of
problems that Paradox users have been reporting with Paradox files that
are hosted by an NT server.  Microsoft has been pointing the finger at
their VXREDIR.VXD (i.e. the heir-apparent to SMARTDRV.EXE), and maybe
there is indeed a problem with that, but between you and me and the
fencepost, I think that having the NETBEUI protocol in the picture in
the first place could well be -a- root cause of the problem.

It seems to me that when there exists more than one choice of protocols
that could be used to connect "tither" and "yon," the fact that NT or
the client can choose betweeen NETBEUI and TCP/IP could be creating a
lot of timing-related problems that are ultimately causing what we have
all been experiencing with NT.

NETBEUI, by and large, is an anachronism.  As Robbie points out, NT can
accomplish the same networkning over TCP/IP.  But if NETBEUI is listed
as a contender, fundamental timing-problems seem to occur.

What have the rest of you encountered?  :-{  Let's start a thread here.

Quote
>Robbie wrote:

> Eric Grajales <er...@knight.simsol.com> wrote:

> >I have a Delphi4 application that shares data on an
> >NT 4.0 Server.  The first client that accesses the data
> >is quick and responsive, when the second client accesses
> >the data, the response slows down 10 fold.  As more users
> >access the server the slower the system becomes.
> >The clients are running Win98.

> >We recently converted from a Novell Server that did not
> >have this problem.

> >Has anyone encountered this problem or have any suggestions.

> >Eric G.

> Eric,

> I had a similar problem on a network I installed recently.

> I was using NETBEUI & TCP/IP on all W/S and the server and found the
> network was running like a sick dog. I have 100BaseT cards installed
> everywhere and couldn't beleive the poor network responses. I got rid
> of NETBEUI on the server and everyone was happy again.

> Are you using MS NETBEUI on the server? if so, get rid of it and use
> TCP/IP instead. and let NETBIOS do the windows networking over TCP.

> Note: Microsoft suggest using NETBEUI for windows networking and it
> may work OK if you're only using NETBEUI. From what I found, if you
> add any other protocols, it seems to lose the plot.

> Hope this helps,

> Robbie...

--------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)

- Show quoted text -

Quote
> Why =shouldn't= it be quick and easy to keep your database online?
> ChimneySweep(R):  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/cs3web.htm

Sundial Service

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


I think that Eric will find that if both the NetBEUI and the TCP/IP
protocols are active at the same time, performance can be severely
affected.  You should have the bare minimum number of protocols,
services and so-forth installed to accomplish your intended result.

Quote
>Bruce Roberts wrote:

> "Eric Grajales" <er...@gator.simsol.com> wrote in message
> news:zqOg4.1098$Ve7.27215@iad-read.news.verio.net...
> > no.junk.please....@attcanada.net (Bruce Roberts) wrote in
> > <5kRf4.18403$fy1.1...@tundra.ops.attcanada.net>:

> > >How is the NT server configured? In my experience NT servers require much
> > >more hardware to give the same performance shown by Netware.

> > The server is configured with 256MB of memory, 20 GB Cheeta 10K RPM HD,
> > AMD K2 450 Processor.  The old Netware box was a Pentium Pro 200 with 128
> > MB of memory, and 2 Cheeta 4GB HD.

> > We thought the same thing here, NT requires more hardware and memory,
> > but we thought that the above hardware would be more than sufficient.

> Seems like enough hardware, (although perhaps a little light on memory).
> Have you had an opportunity to check out the NETBEUI suggestions?

> > Eric G.

--
--------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)

- Show quoted text -

Quote
> Why =shouldn't= it be quick and easy to keep your database online?
> ChimneySweep(R):  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/cs3web.htm

Eric Grajal

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


no.junk.please....@attcanada.net (Bruce Roberts) wrote in
<5kRf4.18403$fy1.1...@tundra.ops.attcanada.net>:

Quote
>How is the NT server configured? In my experience NT servers require much
>more hardware to give the same performance shown by Netware.

The server is configured with 256MB of memory, 20 GB Cheeta 10K RPM HD,
AMD K2 450 Processor.  The old Netware box was a Pentium Pro 200 with 128
MB of memory, and 2 Cheeta 4GB HD.

We thought the same thing here, NT requires more hardware and memory,
but we thought that the above hardware would be more than sufficient.

Eric G.

Bruce Robert

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


Quote
"Eric Grajales" <er...@gator.simsol.com> wrote in message

news:zqOg4.1098$Ve7.27215@iad-read.news.verio.net...

Quote
> no.junk.please....@attcanada.net (Bruce Roberts) wrote in
> <5kRf4.18403$fy1.1...@tundra.ops.attcanada.net>:

> >How is the NT server configured? In my experience NT servers require much
> >more hardware to give the same performance shown by Netware.

> The server is configured with 256MB of memory, 20 GB Cheeta 10K RPM HD,
> AMD K2 450 Processor.  The old Netware box was a Pentium Pro 200 with 128
> MB of memory, and 2 Cheeta 4GB HD.

> We thought the same thing here, NT requires more hardware and memory,
> but we thought that the above hardware would be more than sufficient.

Seems like enough hardware, (although perhaps a little light on memory).
Have you had an opportunity to check out the NETBEUI suggestions?
Quote
> Eric G.

Matthias Ostrowsk

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


I had problems, too.
Using D4 and Interbase via BDE, sometimes my apps lost the connection to the
DB- server (NT4+ SP3, later SP4/5/6). "Unable to complete Network request to
host ... " and so on

If your using BDE- Alias then try to connect via TCP/IP, not via NETBEUI.

123.123.123.123 be the IP of the DB- Server and D the drive letter, where
the DBfile is located,
then the path
"\\123.123.123.123\D:\AnyDatabase.gdb" would connect via NETBEUI and
"123.123.123.123:D:\AnyDatabase.gdb" connects via TCP\IP

That should work with any DB via BDE, not only with Interbase...

after I changed that, I had no more such problems - but i cannot tell if
that was the only reason, cause we changed a lot more these days. So if this
solves your speed problems ... well, you'd be glad.

Bye

Matthias Ostrowski

Sundial Services <i...@sundialservices.com> schrieb in im Newsbeitrag:
388133B6.3...@sundialservices.com...

Quote
> Following up on Robbie's point, I think the jury is still out as to just
> how much of an impact the NETBEUI protocol is having on the slew of
> problems that Paradox users have been reporting with Paradox files that
> are hosted by an NT server.  Microsoft has been pointing the finger at
> their VXREDIR.VXD (i.e. the heir-apparent to SMARTDRV.EXE), and maybe
> there is indeed a problem with that, but between you and me and the
> fencepost, I think that having the NETBEUI protocol in the picture in
> the first place could well be -a- root cause of the problem.

> It seems to me that when there exists more than one choice of protocols
> that could be used to connect "tither" and "yon," the fact that NT or
> the client can choose betweeen NETBEUI and TCP/IP could be creating a
> lot of timing-related problems that are ultimately causing what we have
> all been experiencing with NT.

> NETBEUI, by and large, is an anachronism.  As Robbie points out, NT can
> accomplish the same networkning over TCP/IP.  But if NETBEUI is listed
> as a contender, fundamental timing-problems seem to occur.

> What have the rest of you encountered?  :-{  Let's start a thread here.

> >Robbie wrote:

> > Eric Grajales <er...@knight.simsol.com> wrote:

> > >I have a Delphi4 application that shares data on an
> > >NT 4.0 Server.  The first client that accesses the data
> > >is quick and responsive, when the second client accesses
> > >the data, the response slows down 10 fold.  As more users
> > >access the server the slower the system becomes.
> > >The clients are running Win98.

> > >We recently converted from a Novell Server that did not
> > >have this problem.

> > >Has anyone encountered this problem or have any suggestions.

> > >Eric G.

> > Eric,

> > I had a similar problem on a network I installed recently.

> > I was using NETBEUI & TCP/IP on all W/S and the server and found the
> > network was running like a sick dog. I have 100BaseT cards installed
> > everywhere and couldn't beleive the poor network responses. I got rid
> > of NETBEUI on the server and everyone was happy again.

> > Are you using MS NETBEUI on the server? if so, get rid of it and use
> > TCP/IP instead. and let NETBIOS do the windows networking over TCP.

> > Note: Microsoft suggest using NETBEUI for windows networking and it
> > may work OK if you're only using NETBEUI. From what I found, if you
> > add any other protocols, it seems to lose the plot.

> > Hope this helps,

> > Robbie...

> --------------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> mailto:i...@sundialservices.com  (PGP public key available.)
> > Why =shouldn't= it be quick and easy to keep your database online?
> > ChimneySweep(R):  "Click click, it's fixed!" {tm}
> > http://www.sundialservices.com/cs3web.htm

Robb

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


Quote
Sundial Services <i...@sundialservices.com> wrote:
>I think that Eric will find that if both the NetBEUI and the TCP/IP
>protocols are active at the same time, performance can be severely
>affected.  You should have the bare minimum number of protocols,
>services and so-forth installed to accomplish your intended result.

>>Bruce Roberts wrote:

>> "Eric Grajales" <er...@gator.simsol.com> wrote in message
>> news:zqOg4.1098$Ve7.27215@iad-read.news.verio.net...
>> > no.junk.please....@attcanada.net (Bruce Roberts) wrote in
>> > <5kRf4.18403$fy1.1...@tundra.ops.attcanada.net>:

>> > >How is the NT server configured? In my experience NT servers require much
>> > >more hardware to give the same performance shown by Netware.

>> > The server is configured with 256MB of memory, 20 GB Cheeta 10K RPM HD,
>> > AMD K2 450 Processor.  The old Netware box was a Pentium Pro 200 with 128
>> > MB of memory, and 2 Cheeta 4GB HD.

>> > We thought the same thing here, NT requires more hardware and memory,
>> > but we thought that the above hardware would be more than sufficient.

>> Seems like enough hardware, (although perhaps a little light on memory).
>> Have you had an opportunity to check out the NETBEUI suggestions?

>> > Eric G.

Interestly enough, when I worked for my last employer, we ran a Novell
network and each workstation had IPX/SPX, NETBEUI & TCP/IP installed.
The server had IPX/SPX & TCP/IP installed. Nobody ever complained
about poor network performance.

Then again, Novell does not support NETBEUI, I wonder why?

Robbie...

Eric Grajal

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


Thanks to all that responded,

Well, after several days of tracking down what was wrong with the
network. We found the following:

1. Check your hubs/switches (there are some dip switches on some devices
   to force network speed and duplex), connectors, and cables.
   We had some bad connectors and some none Cat-5 cables. (Also had a
   hub that only had two ports that were 100, all 16 others were 10).
2. Only use one network protocol on the network.
3. Set the network adapter to auto detect speed and duplex.
   (If we forced our server card to 100/Full the system crawled,
    however when we set it to auto detect, the network card
    selected 100/half and worked like a charm).
4. Give the NT server more disk cache and I/O memory.
   I used a utility called X-SetUp by Xteq to find these settings.
5. Monitor network performance using a tool like:
   LinkView by Wavetek Wandel Goltermann, Inc. (They provide an
   evaluation version that works for 5 minutes, this tooled allowed
   us to evaluate how the changes to the NIC and system registry
   affected network performance)
6. Read the following articles:
   a. Performance Tuning NT 4.0 by Robert L. Hummel (at MS site)
   b. Optimization and Tuning of Windows NT by
      Scott B. Suhy (at MS Technet Site)
   c. Monitoring Performance at
      http://technet.microsoft.com/cdonline/Content/Complete/
             windows/winnt/Winntas/manuals/concept/xcp08.htm
7. Set the BDE Shared Local to True on all machines on the network.
8. Set the BDE Network drive to //Servername/SharedDirectory on all
   95/98/NT systems.

Using the above, our network used to transfer a 10 MB file to a
workstation in 50sec, it now takes under 5sec. Our BDE app improved
similarly.

There is a lot of information about how to monitor your network, however
there is not any information that I found that explained what to
do to try and correct these problems.  What registry entries do you
change, what hardware settings, etc?
Most suggestions were buy better hardware?

We still do not know why our NIC cards won't auto sense to 100/Full,
if I find out I'll leave another message.

Thanks
Eric G.

Bruce Robert

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:Slow paradox table access on network


Thanks for the info.

Quote
>2. Only use one network protocol on the network.

Easier said than done.

Quote
> There is a lot of information about how to monitor your network, however
> there is not any information that I found that explained what to
> do to try and correct these problems.  What registry entries do you
> change, what hardware settings, etc?
> Most suggestions were buy better hardware?

Sigh . . .
It's the easy way out and given the complexity of current systems perhaps
the only way. With the relative cost of hardware and time its probably the
most cost effective as well.
Quote

> We still do not know why our NIC cards won't auto sense to 100/Full,
> if I find out I'll leave another message.

> Thanks
> Eric G.

Other Threads

1. Slow BDE access to Paradox table on Peer-to-peer network

2. SOS : very slow access to network paradox tables...

3. Slow Access of Paradox tables on Novel network drive

4. slow access to paradox-database on a network

5. Slow Paradox 7 tables on network app.

6. Slow Paradox tables on network

7. Strange problem with slow acccess to networked paradox tables

8. network paradox table: too slow

9. Slow access to tables on Novell network

10. Sped of access REAL slow for Paradox 7 table