Unacceptable performance for version 10.2.1

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

I have not noticed this, nor do I believe that anyone has raised any RPIs about this. If you can figure out what is causing the slowdown, we would be interested in investigating further. To that end, the config option FILE-TRACE-TIMESTAMP set to TRUE will put timestamps in the error file. Can you compare the results of that error file when using 10.2.1 vs 10.2.0?

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

The issue they are more than likely having is if they open up any files Output or open any files that do not currently exist. The performance with 10.2.1 is rather slow on this because it is doing the retries on the files. I believe ECN-4545 is your culprit. This ECN was created to help stop errors that were happening under Windows 7 with mapped drives, for us it was 3707 errors. We have a program that opens quite a few temporary files that we open output as the program starts and there is quite a bit of lag as those programs load. With 10.2.1, and our patch to 10.1.0 that has this ecn, it takes about 5 or 6 seconds to load. If we change the new MAPPED-RETRY-DEL-COUNT, MAPPED-RETRY-OPEN-COUNT and MAPPED-SLEEP-MILLSEC configuration variables to 0, the program opens up virtually instantly. For right now, the delay is something that we have to live with because it has stopped the 3707 errors for us. If you have never encountered those issues change those configuration variables and things will speed back up.

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

Information about the runtime error

We did look forward to runtime 10.2.1 because it maybe will help for some of our problems with file errors customers of us have discovered lately.

We did an upgrade on one of our customers 13. of December that runs on terminal-servers and mapped disk. After one hour we have to get back to 10.1.1 because the performance was really bad.

Then we started to check what is the problem and luckily for us this forum post was started. The latency is only because of the new function retry 5 times in file-opening.

Here is what we found:

Problem 1, File_prefix
- We have three libraries with files and programs, one for programs, one with client data and one common library all the clients use
- This we have set in the environment File_Prefix
- Opening a file within the client library is no problem
- But opening a file in the common library give us latency, and as scottmeiners said, about five seconds
- If we set file prefix for the common library before opening a file in the common area, it works with no latency
- But we have to reset it to the original File_prefix

Suggestion to solve it in the runtime
- If you don’t use the new mapped functions until you have tried to open the file on all of the file-prefix-libraries, it will solve our latency problem on files in common library

Suggestion for developers using AcuCobol
- Before you do an open file in common library, set the environment for “FILE_PREFIX” to the common library
- But before you do that, get the original File_prefix” with Accept from environment “FILE_PREFIX” so you can turn it on afterwards

Problem 2, Open output
- When we open a file with output, the latency problem is happening even the file exist or not
- It also happens if we set the file-prefix only to the library we try to open it in

Suggestion to solve it in the runtime
- When the file don’t exists, you don’t need to use mapped functions
- When you got an exception telling you concrete that the file exists before, you don’t need to use mapped functions

Suggestion for developers using AcuCobol
- Before you do an open output, set the environment for MAPPED-RETRY-OPEN-COUNT to zero
- But before you do that, get the original value with Accept from environment “MAPPED-RETRY-OPEN-COUNT” so you can turn it on afterwards


Suggestion for testers to discover the problem in programs
- Increase the values of this settings in the runtime config file to a value that give you enough delay that you can find it in the debug-file with FileTrace 10 set or when debug the program manually:
o MAPPED-RETRY-DEL-COUNT 100
o MAPPED-RETRY-OPEN-COUNT 100
o MAPPED-SLEEP-MILLSEC 100

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

Have anyone registered this as an issue? If not, I will.

Best regards,
JanMorten

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

You should, because even with the mapped-retry settings to zero, it's still slower. In particular at opening files.

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

Hello Ruud, Theo opened an incident with me Incident 3180859 and the last info in it was that setting the MAPPED-RETRY-DEL-COUNT, MAPPED-RETRY-OPEN-COUNT and MAPPED-SLEEP-MILLSEC configuration variables to 0 solved the performance issue, but I have reopened the issue as you write there still is an performance slowdown between V10.2.0 and V10.2.1 I will ask Theo to create file traces.

best regards,

Piet

Hello everyone,

is anyone using the new 10.2.1 version already?

I don’t know what has changed, but the performance of this new version is unacceptable!

It takes at least 10 times more to startup a program (opening of all the files and initiation of the program).

Best regards,

Ruud Hoogendoorn

Hello Ruud,

I received an email from your colleague Theo this morning that he tested one of your heaviest I-O intensive programs at your customer using 10.2.0 and 10.2.1 with the MAPPED- runtime configuration variables set to Zero and with both runtimes the time to run that program (measured with FILE-TRACE-TIMESTAMP TRUE ) was the same.

Please speak to him about the results.

I have closed incident 3180859 again.

Best regards,

Piet Henskens
Micro Focus