Hello folks,

After upgrading some of our clients from 16 to 32bit, the system runs slower, and we're not sure why. Other clients experience performance improvements, and others don't have any performance change. We're trying to figure out why things slowed down. Nothing in the application changed that would of caused such a drastic effect. I have two scenarios, one much worse than the other.

Scenario #1:

Server: NT 4, sp6, with Revelation Service 1.5

Workstaitons: NT 4, sp6

Driver: All networks 1.5.0.0

Network: 100MB, about 40 interconnected servers

After upgrading to 32bit, they noticed a significant decrease in performance. We tried several things:

Verified REVPARAMS

Changed the OI driver to something else, then back to 1.5

Rebooted the server

Application runs fine on a local machine or on the server.

Nothing in the network changed, and the old 16bit runs fine.

Scenario #2:

Server: Windows 2000, all service packs applied, with NT Service 1.5

Workstations: Windows 2000,all service packs applied

Driver: All networks 1.5.0.0

Network: 100mb, about 25 interconnected servers.

In this case, there was a slowdown in performance, but not as significant as in Sceanrio #1. I actually got a chance to do some timing tests, and compared the 16bit vs. the 32bit version, and found the 32bit was slower when loading, reading records and selecting records, about 1.5 seconds slower on average.

In both scenarios, the users expected an increase in performance. I know we could try the 2.1 service IP protocol, but the point is, they shouldn't have to buy that after spending money on the 32bit upgrade to make it run better than the 16bit version.

I know about the LHStats program, but it doesn't give any information about speed (bits/second, avg wait, etc.) that I can tell anyway.

Has anyone out there experienced similar problems? I am looking for just about anything at this point.

I really appreciate any help or suggestions.

Thanks!

Brock Prusha

bprusha@mapcon.com

Brock - this is counterintuitive, in the sense that most users have reported faster performance on OI32 than OI16.

How are the Windows Shortcuts configured? Have you adjusted the idle sensitivity? Are you enabling background processing on the shortcut? Are you using pifs to batch files or shortcuts straight to the exe?

Have you lifted the number of file handles on the workstations in config.nt to 200?

Are there any other concurrent applications ? (virus checkers which may be hammering the *.OV's?) What is the largest file size??

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

This may have nothing to do with performance, but you should look at upgrading your NT Service from 1.5 to 2.1

The 1.5 has the 64K limit built into it which the 2.1 does not and could cause problems in the future.

Deirdre

]]I know about the LHStats program«

Sorry to butt in, but what is the LHStats prog?

Barry

LH2_STATS is the IP equivalent of NLM_STATS. Just what any good OI network admin person would give his/her eye teeth for, like gold. Indeed cant be had at any price. Be patient.

I would have thought Brock will have identified his problem is net or IP related. OI v4.1x itself is quite considerably faster than its 16bit forebear, and getting faster and better with every release. I believe the latest win2000 service also delivers speed improvement.

Richard Bright

BrightIdeas New Zealand

First off, thank you for your response.

The shortcut is configured the same as it was for the 16 bit. In this case, they are using Mapped Drives. We have tried UNC, but that didn't help. There are no other external programs running. Virus checker was disabled. The icon goes straight to the .EXE without using any sort of pif. Largest file size would be at least 100MB maybe more, it probably contains over 200,000 records.

I realize the 2.1 service is "supposed" to improve speed, but I can't tell a client to spend more money to solve a problem that shouldn't be there. And I'm not worried about the 64K issue until I solve this one.

As you know, this is a very simple upgrade process. We copy down the system, upgrade it, copy it back up to where it was before. Could there be a problem with some external DLL or EXE file? Nothing else changed. The IP protocol and addresses are the same. The workstations and the server are the same.

I agree, this does not make sense, but it is happening. Hence, the reason I am asking for help. Again, this is with an NT4 Server/workstation network. The windows 2000 systems seem to be better off.

The only think I haven't verified yet is the 200 file handles. If that is it, I'll do a back flip in my chair, which would be amazing considering my weighty stature. Perhaps I'll take a video.

Thanks to all of your suggestions. Anymore?

Brock Prusha

bprusha@mapcon.com

Brock,

Could there be some kind of DNS lookup problem?  I have seen slowdown occur when DNS is configured such that there is a long pause as it tries invalid DNS server entries and has to wait on a timeout.  Just an idea...

How does the speed of the 32-bit version compare to the speed of the 16-bit version when both are *NOT* using the NT Service (in other words, in NPP mode)?

How about the amount of memory on the workstations?  I could imagine the greater memory requirements of the 32-bit version causing more disk swapping in a machine with minimal memory.

Pat

I really appreciate your insight Pat!

]Could there be some kind of DNS lookup problem? I have seen slowdown ]occur when DNS is configured such that there is a long pause as it ]tries invalid DNS server entries and has to wait on a timeout. Just ]an idea…

We considered this, but trying to convince IT of that when 16bit worked fine is difficult. How much difference is there between the 16 and 32bit versions in this area?

]How does the speed of the 32-bit version compare to the speed of the ]16-bit version when both are *NOT* using the NT Service (in other ]words, in NPP mode)?

Not sure, but we'll see.

]How about the amount of memory on the workstations? I could imagine ]the greater memory requirements of the 32-bit version causing more ]disk swapping in a machine with minimal memory.

Since these are NT workstations, I think they have at least 128MB, if not more, but I'll check.

Thanks again!

]]]We considered this, but trying to convince IT of that when 16bit worked fine is difficult. How much difference is there between the 16 and 32bit versions in this area?«<

There is not very much difference at all in the LH code, the hunch is that maybe there is a difference in the Windows 32-bit system call used versus the Windows 16-bit call used.

I think what I would to do try to figure this one out is to create a very simple test program that times opening, selecting, readnexting, and reading through a file.

LH behind the scenes opens and closes files in an LRU algorithm, so the above DNS lookup theory would only occur when a file is opened. To test this, a FLUSH statement will force all LH files to be flushed and closed, causing the next access of any file to incur the overhead of an open. Try the above timing test both after a FLUSH and after a dummy read of any record of the file (to ensure an open is not required).

Pat

Okay Pat, that makes sense.

One thing though, our application (since it was converted from dos) uses a FOPEN command to store file handles for each file used in the system, that way it doesn't need to reopen the file every time. We didi this back in the dos days to speed things up, especially when files may have been opened 20-30 times due to recursive programs, etc.

I realize this really isn't necessary any more, but it doesn't hurt anything….does it? I wouldn't think so.

Thanks again!

Brock,

Caching open file handles should not hurt anything.  However, you are just duplicating the open file cache being maintained by the system in the SYSTABLES file.

Pat

Have you seen this link?

http://www.revelation.com/WEBSITE/knowledge.nsf/ec0a0b99c363fb31852566f50065224a/ae59e9abff37893f85256848005d009e?OpenDocument

Brock,

What happens if you upgrade from Service Pack 6 to 6a ??

The Sprezzatura Group

World Leaders in all things RevSoft

Steve

View this thread on the Works forum...