Datastore Windows Handle Fix Speeds up Background Processing on Windows Server

[glenn_barber]

We have a powerbuilder module in PB 12.6 Classic which runs as multiple parallel background tasks.

While this runs efficiently on Windows 7 Pro - when we moved it to Windows Server 2012 R2 - it ran much slower regardless of the performance of the servers and database it was running with.

We seemed to be throttled at about 8 background tasks - adding more tasks just slowed down the overall throughput.  And the CPU resource never got past 20% no matter what we threw at it - a huge bottleneck

We spent weeks investigating the OS configurations, Database tuning, Fairshare Scheduling, BIOS adjustments - all to no avail.

I noticed that our tasks were gaining memory size as they ran - and we investigated memory leaks of various types.

Talking with SAP support about a separate issue, I happened to bring up the memory issue, the tech mentioned a case about how datastores were using windows handles and that it could be turned off.  He send me the following.

The following url is to the article that explains the issue with datastores and handles.

http://search.sybase.com/kbx/solvedcases?id_number=11689586

The following is what you would put in the pb.ini file.

[DataStore Behavior]
UseHwnd=no

As the article mentions, there is no known side effect to turning off Windows Handles on Datastores.

This turned out to be a miracle cure for the throughput problem with our application.  Now we can run 24 tasks or more at 4-5 times the throughput utilizing 80-100% of the CPU if we need it.

I see various posts about unexplained slow performance when moving non-visual background apps to Windows Server 2012 - perhaps this is the cure.

As this is not a well known fix  I hope everyone in the community can share the discovery.  Also I feel that Engineering should have fixed the problem rather than issue an obscure getaround.

Glenn Barber

[Former Member]

it sounds like that they have this backwards - by default PB should not use windows handles for datastores, and a special value to turn it on.

[Former Member]

Baah!  There you go, trying to confuse us with your pesky logic.

To take that a step further -  if you can turn this "feature" off why is handle usage needed in the first place? The case notes specifically state that there are no side effects.  How much additional effort was spent implementing this switch when handles could have been removed from the datastore logic completely, solving this issue everywhere!

[glenn_barber]

The reason for this, was that at the time this seemed to be an obscure issue and there wasn't the time and resources to focus on regression testing by turning it off generally.

Also note that SAP still doesn't officially support Windows Server 2012 deployment - which is where this seems to have the most impact.  From what I understand Server 2008 was more like Windows 7 - whereas architecturally 2012 R2 is a whole new environment - which I can confirm - its much, much better.  We are doing a lot of cloud deployment using it and it has re-invigorated our business.

Why they don't support a two year old major version of Windows is a bigger mystery to me.

[tobias]

Hello everybody,

amazing! It solved some problemes with us. Thanks for this thread!

Are there any other "magic things" that I should know? 😉

regards,

Tobias

[glenn_barber]

Hi Tobias

When I discussed this with support, they said

"One of the things we’re in the process of doing in support since the switch to SAP is gathering all the undocumented pb.ini properties and documenting them.  There have been a number of them over the years.".

So perhaps there are more.

I do have one giant magic fix that I have been trying to get the word out on and will start a separate thread on.  PowerBuilder windows apps run faster in the cloud using Windows Server 2012 R2 remote app publishing then they ever did on a desktop - with no recoding.  I've been running my customers on this for almost two years now.  Incredibly fast - except the background processing which we just fixed.

GB

[Former Member]

Hi Glenn,

I can confirm. This little pb.ini file makes magic.

Our team found this "undocumented trick" and our application stop crashing after years dealing with windows resources problems, unespected crashes "without cause", slow performance, etc ...

[Former Member]

How does this help an executable deployed to a different server if it is in the developer's pb.ini file? Does it somehow change how the exe is created?

[glenn_barber]

Usually we only use the PB.ini to control how the development environment works - but in this case this particular tweak affects how the runtime performs and you deploy it (pb.ini) with your application on the target.

We were a little surprised by this as well - as we have never deployed pb.ini with our runtimes and there is no mention of it in the deployment docs nor is it a selectable add in in the MSI wizard.