I have several clients who complained a reduction in performance after upgrading their servers and work stations following Microsoft stopping support.

Upon further investigations here are my findings:

[list=1]

Copied application (OI9.4.4) from my Surface book laptop (512Gb SSD) to and 10 year old windows 7 desktop.

Run the report on the windows 7 desktop 12 seconds.

Run the report on my windows 10 laptop took 32 seconds.

Client running the report (via RDP) on server2008R2 14 seconds.

Client running the report (via RDP) on server 2019 43 seconds.

[/list]

All servers have the OV, LK and revparam exclusions. I do not believe it is an antivirus issue.

The desktop and Laptop tests are stand alone NOT running linear hash.

I believe there is serious performance issue running OI on windows 10 and server 2019. Surely I am not the only one experiencing the same issue.

Any advice would be grateful.

Chris

Did you re-run the ClientSetup on the new workstations?

Don Bakke

SRP Computer Solutions, Inc.

Are you implying that running the client setup will slow things down by a factor of three. My laptop development system is up to date with all the latest patches etc and still run 3 time slower than the old windows 7. I copied the latest version from my laptop to the windows 7 desktop this morning to verify my suspicion that windows 10 and server 2019 with similar underlying OS severely impact the performance of OI9.4.4.

Chris

Are you implying that running the client setup will slow things down by a factor of three.

No, the opposite. The client setup will install critical files needed for proper running of OpenInsight. One of them is critical for proper queries using indexes.

Don Bakke

SRP Computer Solutions, Inc.

Thanks Don,

I have a inventory report that selects the required records with 1 second (Btree, 4731 records), then step through each record to create the OIPI (classic) report. I have a gas gauge to display the progress and for testing, put a start and finish time to display the time taken for the report. The difference between windows 7 and windows 10 is almost 3 fold.

My IT expert who has also spent some time trying to track this down and came to the same conclusion that the latest Microsoft OS has impacted OI performance independent of antivirus, networking etc.

Other complaints have been when opening a form and start typing into the first control, the first 2-3 characters are missed.

I was hoping someone at Revelation could look into verifying my suspicion and if other developers have seen a similar degradation of OI performance.

Chris

Hi, Chris. A couple of questions.

Is the newer OI also running OIPI "classic", or is it defaulting to OIPI.Net? There's a well known performance dropoff in OIPI.Net, so that may be part of it.

Also, note that Microsoft made significant changes to the OS to increase security - they closed some vulnerability "holes" by patching instruction sets, with the admitted drawback of decreasing performance by 30%. So some of what you may be seeing is the difference in OS. (I can find you the links if you don't remember when this happened - it was a big deal).

Have you tried running your older OI on your newer systems? From your initial posting, it looked to me like maybe you were running old OI on old system vs new OI on new system - did I misunderstand?

Thanks!

- Bryan Shumsky

Revelation Software, Inc.

Hi Chris,

I believe the issue is related to SMB

See

https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/slow-file-transfer

That article says transfer of large and slow files is slow. Unfortuately transfer of large and small files is what Revelation Software does. To mitigate, you can try putting the binaries closer to the users by deloyiing everything except the .LK and .OV files to the terminal server or even the local workstation, then using a revparam with a sharename to access the linear hash data on the UD server. This keeps the binaries and the revparam file being read via SMB.

Maybe I did not explain my performance testing properly.

I had an old windows 7 desktop laying around. So I copied the latest OI9.4.4 from windows 10 laptop to the old windows 7 desktop. Same OI9.4.4 and application on both windows 7 and windows 10 running OIPI classic (NOT OIPI.net)

Windows 7 report 12 seconds

Windows 10 report 32 seconds

Using the report performance was easy to measure but there are performance issues with rendering forms, hovering over radio buttons etc. Month end process from 15 minutes to 45 minutes and all clients complaining after upgrading their servers from Server 2008R2 to server 2019.

This is NOT an indexing or antivirus issue.

I was avoiding a fresh OI9.4.4 install as this will take some time with promoted events, SRP controls, inherited accounts etc. Even a new OI install is no guarantee will fix the problem.

Surely I am not the only one having these issues.

BTW Bryan your 30% reduction has a zero missing, it is closer to 300%. I could live with a 30% reduction.

If you need any further details please let me know.

Chris.

If you need any further details please let me know.

I think it would be helpful if you ran benchmark tests that targeted different parts of the application. That is, let's figure out exactly where the bottlenecks are occurring. Create a routine that does straight database I/O comparisons. Then create a routine that does straight computational comparisons. Etc. It's a bit of work (I know…I've had to do this many times) but it really will help to identify where the problematic areas are. You may very well discover the problem permeates everything, but you might also find that some areas are more impacted than others. Knowing this will at least help to prioritize the troubleshooting and hopefully get reasonable performance back while other issues are still being investigated.

Don Bakke

SRP Computer Solutions, Inc.

Hi Don,

Do you have any benchmark tests in mind?

Any advice would be appreciated.

Chris.

Hi Don,

Found the offending routine. I have a gas gauge to indicate the progress of the report.

With the gas gauge 32 seconds

Without the gas gauge 3 seconds (10 times faster)

I still have the question why windows 7 desktop is 3 times faster than windows 10 laptop.

What is a replacement for the gas gauge instead of just displaying a message "Please wait…". Psychologically things seems to go quicker is there is some movement taking place.

I have gas gauges throughout my application not realising there is such an impact on performance.

An alternate solution would be great.

Any assistance would be much appreciated.

Chris

Hi Don,

Found the offending routine. I have a gas gauge to indicate the progress of the report.

With the gas gauge 32 seconds

Without the gas gauge 3 seconds (10 times faster)

I still have the question why windows 7 desktop is 3 times faster than windows 10 laptop.

What is a replacement for the gas gauge instead of just displaying a message "Please wait…". Psychologically things seems to go quicker is there is some movement taking place.

I have gas gauges throughout my application not realising there is such an impact on performance.

An alternate solution would be great.

Any assistance would be much appreciated.

Chris

Hi Chris - I'm very glad to see that you've been able to isolate the most offending element in your application. I apologize for not responding to your previous post, I've been working against a deadline with a very important project.

When you say you are using a gas gauge, are you referring to the feature of the Msg() function to work like a gas gauge? We've never used that method. We simply wrote our own modeless dialog and use the SRP Statusbar control (which you have licensed) for the visual effect.

I am wondering if you can mitigate the performance issues simply by reducing the number of calls to Msg(). How frequently do you update the progress bar? For instance, are you doing it during every iteration or do you delay after so many iternations?

Don Bakke

SRP Computer Solutions, Inc.

Thanks Don,

Are you implying the SRP Status bar does NOT have a performance issue.

BTW. Yes, I can reduce the number of MSG() calls but in doing so I loose the cancel facility as below:

While  Msg(@window, MsgUp, recsdone, MSGINSTUPDATE$)

replaced by:

		MsgCount += 1

		If MsgCount > 50 then

			Void =  Msg(@window, MsgUp, recsdone, MSGINSTUPDATE$)

			MsgCount = 0

		end

OR is there another way if telling the user there is some progress, a gas gauge replacement. Some users think the system has hung if it takes too long and windows goes milky.

What is the use of the gas gauge if it has this performance issue. The whole idea is to tell the user there is movement and while there is something to look at it psychologically goes quicker.

Any ideas would be grateful.

Chris

Thanks Don,

Are you implying the SRP Status bar does NOT have a performance issue.

BTW. Yes, I can reduce the number of MSG() calls but in doing so I loose the cancel facility as below:

While  Msg(@window, MsgUp, recsdone, MSGINSTUPDATE$)

replaced by:

		MsgCount += 1

		If MsgCount > 50 then

			Void =  Msg(@window, MsgUp, recsdone, MSGINSTUPDATE$)

			MsgCount = 0

		end

OR is there another way if telling the user there is some progress, a gas gauge replacement. Some users think the system has hung if it takes too long and windows goes milky.

What is the use of the gas gauge if it has this performance issue. The whole idea is to tell the user there is movement and while there is something to look at it psychologically goes quicker.

Any ideas would be grateful.

Chris

Keep the cancel by doing (I think):

Loop

.

.

              If mod(recsdone,50) = 0 then

		NotCancelled =  Msg(@window, MsgUp, recsdone, MSGINSTUPDATE$)

	end

while NotCancelled

Are you implying the SRP Status bar does NOT have a performance issue.

No, not at all. I was only saying that we have always used our own solution. The reason being we wanted better control and, quite frankly, the Msg() function approach to a progress bar was never visually attractive to us.

BTW. Yes, I can reduce the number of MSG() calls but in doing so I loose the cancel facility as below:

Displaying progress that is meaningful and responsive has always been a balancing act.

OR is there another way if telling the user there is some progress, a gas gauge replacement. Some users think the system has hung if it takes too long and windows goes milky.

What is the use of the gas gauge if it has this performance issue. The whole idea is to tell the user there is movement and while there is something to look at it psychologically goes quicker.

Yes, I think we all understand this. The problem is that in operations like this, OI is single threaded and everything is synchronous. Thus it is hard to do anything like this without seeing an impact on performance. This is why we do tend to update the progress in greater intervals. Yes, we lose some granularity, but I've rarely found that to be a problem as long the the progress continues to show movement at a reasonable pace.

Don Bakke

SRP Computer Solutions, Inc.

View this thread on the Works forum...