Anonymous_User Absent Member.
Absent Member.
2535 views

slow database access

I have a db application at one of our remote offices, that is peforming
very poorly on their NetWare server. It's more like portions of the
application perform poorly. In any case, I have replicated the slow
performance on numerous servers (NetWare 5.1, 6.5 and even on an NSS
OES/Linux server. If I simply copy the dataset over to one of our windows
2003 servers, it works great. (A query on NW=2min+ and on
windows2003=5sec). I'm sure it is a client/ncp issue but I don't know why.

I've done a few packet traces and a very tiny sampling is shown below: The
thing to know is that within seconds, I'll get ten of thousands of packets
basically performing the following sunctions over and over (btw, I think
the retransmissions shown below are some bug in Ethereal as they are not
really there. Also, I've read some threads on Ethereal's site stating the
unreassebled packets are not really an issue either).

Back to the issue, I get the same performance issues on ipx as well, which
would make sense as it's still NCP, just over a diffently proto, but
thought it was worth mentioning. I've tried many many different client
setting (file cacing/file commit/pburst, sig level, etc with no
improvement). Any ideas/thoughts would be appreciated!!!!

C Clear Physical Record[Unreassembled Packet]
C Log Physical Record[Unreassembled Packet]
C Read From A File[Unreassembled Packet]


73300 6.922571 10.1.1.15 10.1.3.224 NCP R OK
73301 6.922575 10.1.1.15 10.1.3.224 NCP [TCP
Retransmission] R OK
73302 6.922993 10.1.3.224 10.1.1.15 NCP C
Clear Physical Record[Unreassembled Packet]
73303 6.922995 10.1.3.224 10.1.1.15 NCP [TCP
Retransmission] C Clear Physical Record[Unreassembled Packet]
73304 6.923026 10.1.1.15 10.1.3.224 NCP R OK
73305 6.923030 10.1.1.15 10.1.3.224 NCP [TCP
Retransmission] R OK
73306 6.923287 10.1.3.224 10.1.1.15 NCP C
Log Physical Record[Unreassembled Packet]
73307 6.923290 10.1.3.224 10.1.1.15 NCP [TCP
Retransmission] C Log Physical Record[Unreassembled Packet]
73308 6.923321 10.1.1.15 10.1.3.224 NCP R OK
73309 6.923325 10.1.1.15 10.1.3.224 NCP [TCP
Retransmission] R OK
73310 6.923570 10.1.3.224 10.1.1.15 NCP C
Read From A File[Unreassembled Packet]
73311 6.923572 10.1.3.224 10.1.1.15 NCP TCP
Retransmission] C Clear Physical Record[Unreassembled Packet]

Labels (1)
0 Likes
5 Replies
Anonymous_User Absent Member.
Absent Member.

Re: slow database access

skcgeek,

What version and SP of Windows and the Novell Client?
Lets stick with IP-only being that its the best supported.

Go thru these lists and let us know which, if any, of these steps help with
your delays...

Slow application performance with Novell Client 4.83 for NT/2K/XP
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10076527.htm

Enhance Client32 Performance
http://www.ithowto.com/novell/clientspeed.htm

Performance, Tuning and Optimization
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10012765.htm

--
Tony Pedretti


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: slow database access

Thanks for the response!!!!

I assumed that the problem was with client/32, so that's where I've been
focusing my attention. With your post though, I thought I better stop
assuming and I'd removed client/32 and added the MS client for NW and
perforrmance was just as bad, which surprised the heck outta me!!!

Soooo:
NWClient >> NW server = 2 minutes (for a canned test..regardless of protocol)
MS client for NW >> NW server = 2 minutes (for the same test)
MS client >> MS Server = 10 seconds (for the same test)

So, this would make me want to change my focus to that of the server. I've
disabled level2 op locks, disabled client file caching, packet sig=0. None
have affected the tests at all. I'm in a quandary. I feel it's the
application itself, but I need to prove it and two, I would have thought a
NetWare server "should" have similar performance stats.

Any other thoughts would be appreciated....



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: slow database access

Disabling OpLocks will not help, but hurt improvement.
Often OpLocks are disabled due to some inherent issues with oplocks.

( I lost the link when my laptop tanked, but I had one for an MS TID that
said every version of Windows from Win95 through XPSP2 would be totally
re-written to completely fix them.)

On your OES box, ensure that you have the latest greatest patches and that
ALL clients are updated to 4.91 with all of the latest patches.
This removes almost all OpLock related issues.
Once you are in this state, You can re-enable OpLocks.
This should definately help performance.

I would tend to rule out any networking issues since the MS Client and NW
Client show the same results.
IP shows great degradation but not IPX when network issues exist.
Since the MS Client only supports IPX, you are connecting over IPX which
should not show huge performance loss.
Of course this could still be an issue and check your NIC in monitor for
network errors.


<skcgeek@gmail.com> wrote in message
news:jF8Fe.6850$Y_1.2180@prv-forum2.provo.novell.com...
> Thanks for the response!!!!
>
> I assumed that the problem was with client/32, so that's where I've been
> focusing my attention. With your post though, I thought I better stop
> assuming and I'd removed client/32 and added the MS client for NW and
> perforrmance was just as bad, which surprised the heck outta me!!!
>
> Soooo:
> NWClient >> NW server = 2 minutes (for a canned test..regardless of
> protocol)
> MS client for NW >> NW server = 2 minutes (for the same test)
> MS client >> MS Server = 10 seconds (for the same test)
>
> So, this would make me want to change my focus to that of the server.
> I've
> disabled level2 op locks, disabled client file caching, packet sig=0.
> None
> have affected the tests at all. I'm in a quandary. I feel it's the
> application itself, but I need to prove it and two, I would have thought a
> NetWare server "should" have similar performance stats.
>
> Any other thoughts would be appreciated....
>
>
>



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: slow database access

Actually you may want to make sure all OPLOCKS are ENABLED.
Well functioning OpLocks will greatly help performance, but both Novell and
MS often have issues with them.
Try making sure all oplocks are enabled on both the client and the server to
see if that helps.

--
Craig Wilson
Novell Product Support Forum Sysop
Master CNE, MCSE 2003, CCNA

Editor - http://www.ithowto.com

(Seeking Full-Time Expert? Drop me a note 😆 )
<skcgeek@gmail.com> wrote in message
news:jF8Fe.6850$Y_1.2180@prv-forum2.provo.novell.com...
> Thanks for the response!!!!
>
> I assumed that the problem was with client/32, so that's where I've been
> focusing my attention. With your post though, I thought I better stop
> assuming and I'd removed client/32 and added the MS client for NW and
> perforrmance was just as bad, which surprised the heck outta me!!!
>
> Soooo:
> NWClient >> NW server = 2 minutes (for a canned test..regardless of
> protocol)
> MS client for NW >> NW server = 2 minutes (for the same test)
> MS client >> MS Server = 10 seconds (for the same test)
>
> So, this would make me want to change my focus to that of the server.
> I've
> disabled level2 op locks, disabled client file caching, packet sig=0.
> None
> have affected the tests at all. I'm in a quandary. I feel it's the
> application itself, but I need to prove it and two, I would have thought a
> NetWare server "should" have similar performance stats.
>
> Any other thoughts would be appreciated....
>
>
>



0 Likes
kevgo Absent Member.
Absent Member.

Re: slow database access

Wow.. years later and I have the EXACT same issue. If anyone is aware of a solution please feel free to share.

I have all but exhausted all my sig level, OpLock, options..

kevgo.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.