I have a client that is running an OpenEdge RDBMS backend with a database. The software is a POS system that links to that database and uses OpenEdge as an engine. They run Windows Server 2008 with 32GB Ram and a 1TB drive. Speed and space do not seem to be the issue for this customer.
He claims that when finalizing a transaction iun the POS system, there is a 30 second or so lag that occurs about 90% of the time on each of his workstations (Note that a full network diagnostic, router replacement, and rewiring was recently done and that did not fix the issue).
I immediately think that this might be a problem with how the OE database was initially setup in OE Explorer. Perhaps there are not enough users/servers or the ratio's are all wrong. This server is a powerhouse so the lag might be coming from setup.
I can post information on the servers configuration, but wanted to see what the idea setup is and what I could do to reduce lag and maintain database efficiency?
The situation is that this is a customer that I used to support when working for the POS company. Back in the days of being a grunt worker :) and just being told what to do. I have come to learn that this barebones way of installing a progress database could actually be impacting performance. I am not ruling out bad code. The code was always bad in my opinion.
I am freelancing work for these customers that are not getting the appropriate support from that POS software provider. So all I can really do is support the OpenEdge stuff and make sure that runs like a top. Beyond that the POS provider will need to support the bad code (or the customer will need to move on).
Would it, however, be within your remit to identify bad code so that the vendor could fix it? While it is worth checking all the stuff that is being discussed, it is still quite possible that there is a piece of bad code in the commit which is the primary contributor to the performance. If true, you can make it better through tuning, but not fix it. But you could point out to the vendor what was wrong and possibly even tell them how to fix it. This is why I asked the question about past vs current performance since that will give us a clue.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
I am all about solutions.
when employed by the POS provider, we frequently put out outdated and half-baked versions of the software that would introduce new features but break several others. I've identified this version of the software to be 2 years old, and newer code exists but my customer told me the POS provider will not give them the latest code.
As much as I am into solutions, there is a fair amount of bad blood between myself and the POS provider and they would laugh at me if they knew I was helping their customer base as a freelance. I'll do whatever it takes though.
The answer to the question about the pattern of onset is potentially key to deciding whether this is something you can address separately from the vendor or whether they are going to need to be involved.
If the problem is the code and if the vendor won't give them a new version, then I would think that fixing it independently was the only choice. It wouldn't be the first time.