VFP 9.0 Abysmally slow performance on windows 2008 server 4

[dkean4]

Three years ago I installed a little utility for a local company and testing it in a single user environment it was performing slow, but it was workable. When I installed the final version and tested it on 2 terminals concurrently, it slowed down so much, when accessing the DB tables that it became unusable. I read up on that, some, but I never had a chance to fix that problem. It is well known, I'm sure... something about double caching on the newer servers, which needs to be disabled etc. Needless to say, I lost that customer, though my utility was superbly fit for the task.

I am about to do another install, for another app, in a multi-user environment. Any advice on how to tame MS servers, would be appreciated. I am an old time Novel CNE. Is Novell still alive? Are there better servers, than the MS latest incarnations, fit for VFP 9.0?

Let me add that I was using the native DB, not the SQL DB part of VFP, in that app.

Dennis

 

[dbMark]

My workplace has a Linux server hosting all local data. For whatever reason they used Windows Servers only for web services. While it had its hiccups it was doing well until our data load increased. As did nigelgomm, we got numerous 'error reading file r:xxx.dbf' messages. The tech guys worked hard at it over months. One the the final changes - and what really worked best - was that they replaced all the drives with SSDs. (I'm sure they're in a RAID array of course.) Overnight errors virtually stopped.

So my suggestion is that besides just using a dedicated File Server, also fill your RAID array with SSDs for faster response.

A footnote about Novell & Microsoft server history. MS has often told users, in effect, "we may not be the best now but give us time and we'll catch up to the other vendors". That strategy worked against Novell. The following account is from my reading of a law suit Novell filed against them. When MS first came out with a server, it wasn't as robust as Novell. But they won out over time. Of course MS denied and delayed and by the time it got to court the issue was moot, Novell's rep had been damaged. I think the gist of their case was that when MS sold their servers, the behavior favored MS servers and not other servers. So if a data or "who's there" request was made, MS server responses were accepted immediately and other servers had to wait longer before the MS server would stop waiting and accept their responses. So whenever a MS server was installed it would then inexplicably appear faster than the competition. Novell claimed they reported the problem to MS and even told how to correct the issue but MS basically ignored it for over a year. By then the damage was done to Novell's server reputation.

 

[dkean4]

Olaf and Mike,

My solution in the past has been to do record locking. But that locks up other folks at times and I was getting complaints about "No Access". So, my solution was to time limit the locked records. If someone walks away to the bathroom and a record is locked by his terminal, I bumped him out after someone tried for 30 seconds and thrash his changes. It was primitive, convoluted and maybe even puerile, but that was the price of walking away from a marketing station where things are hopping. Then I started getting complaints "When I came back all the work I did was gone". My reply was "Ha ha ha... You won't do that again... will you?"

But record locking across a complex transaction which involves multiple related tables is a nightmare. And that was the explanation that the Architects at Sungard were saying. They called it "Acceptable losses". I saw that as a disaster.

By the way, Olaf. You mentioned WebSockets and I am working furiously to develop a protocol for direct binding across the web. I don't know about you, but I detest the C in web MVC. I see VFP (DBF style) as mostly MVVM. JavaScript and its fleas, like Angular, BackBone, Ext.js etc simply do not go far enough.

With WebSockets, if it can be made to work "client to client bidirectionally", you would not need to glut the server to resolve the locks. Let the "waiting" user auto-ping the "locking" user DIRECTLY and do his "Cursing" to get a release. WebSockets are very interesting and the speed is impressive. Terminals could communicate with each other and resolve the conflicts without the Server. One person is working on the address and the other is changing the telephone number. No conflict and it is resolved by the terminals.

Just a little entertainment for you.

Dennis

 

[dkean4]

MikeLewis

"The point about optimistic locking - and the conflicts that arise from it - is really a business issue, not a technical one.
"

Yes Mike, nicely put and explained.


Dennis

 

[dkean4]

dbMark,

"MS has often told users, in effect, "we may not be the best now but give us time and we'll catch up to the other vendors"."

MicroSoft modus operandi.B-) The development of VFP is the one thing I credit them for, unless that was done by the original FoxPro team, under the MS umbrella.

And yes, SSDs are a perfect match for servers.

DK

 

[Olaf Doschke]

I recently bought tickets for Elbphilharmonie concerts and their way of "locking" a seat was giving seats a reserved status for 20 minutes you had to go through the payment process. Not the worst idea, too.

Bye, Olaf.

 

[Mike Lewis]

my solution was to time limit the locked records. If someone walks away to the bathroom and a record is locked by his terminal, I bumped him out after someone tried for 30 seconds and thrash his changes. It was primitive, convoluted and maybe even puerile, but that was the price of walking away from a marketing station where things are hopping.

What you have described is pessimistic locking. It's not primitive, and is certainly not peurile. It's a perfectly legitimate tactic.

Whether it is the right tactic in your particular case is another matter. It goes back to what I was saying before about it being a business decision.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dbMark]

Besides SSDs to reduce thrashing on our file server, our tech staff also upgraded the power users to 1GB LAN switches and the server to a couple 10GB LAN cards, etc. Anywhere and everywhere there might be a bottleneck.

 

[Olaf Doschke]

In regard of concurrent updates of the same field still with an optimistic buffering strategy, one other famous case is inventory stock. If Olaf and Dennis both start an order processing with a stock level of 4 and both need 3 items of the product in question, this should obviously fail for one of them.

I want to point out both change the value from 4 to 1 and that still correctly is a conflict for the second commit, though both "agree" on the final value 1. Actually both changes are not updates to 1 but decrements by 3 and so the update you really wanted to do was update inventory set stocklevel= stocklevel-3 and not set stocklevel = newstocklevel. Neither TABLEUPDATE nor entitiy framework or anything I knwo do this.

The actual solution still can be achieved by one failing and being informed the stock level got too low during order processing.

Several obvious solutions to this are sequential order processing, better in an automated way than with manual interference and another obvious solution is you rather add a change record, eg openbravo has a stockdiary table. The stocklevel computes from the sumamtion of stockdiary entries and of course you have to sum this soon enough to know you need to either inform a customer you can't deliver or you need to reorder to fulfill an order.

Not long ago I also proposed the typical shopping cart solution removing items from the shelf during a customer order in the same manner as in a supermarket, even though the items are not yet sold and paid, by being in the cart they are reserved and can't be taken twice by another buyer.

To relate this to the performance question: If you can transform updates to inserts by rather having logging type tables, no matter if you then aggregate data to a sum or other current state resulting from such dats asap or in afterhours, the insert of new rows always felt faster to me than update or delete operations.

Bye, Olaf.

 

[dkean4]

Olaf,

Just a quick note on your last comment.
What about this:
1. Olaf fetches the record with 4 items left.
2. Dennis fetches the record with 4 items left.
3. Dennis sells and closes the deal calling a server side script with the sale details. The server does the math and the changes, inspecting availability first. It then responds to Dennis to inform him that it went through.
4. Olaf still reads 4 items on the screen and he tries to sell 3 items. Server says: "Sorry! AvailableItems = 1 "
5. Olaf's customer does a dance and walks out grumpy!

And if some automation is involved to update Olaf's terminal, then He will see it eventually, but most certainly he will see it at the time he tries to sell. Is there a flaw with that?

The only bad there is the addition of disappointment for the customer, I think.

Effectively, the locking is turned over to the server and it is nearly instantaneous to lock and unlock. Right?

But like you said, there are many scenarios. This is good for inventory.

 

[Olaf Doschke]

The main point I have about the different examples is just, that you can't simply determine if there is a conflict potential by overlap or non overlap of fields edited. And the final truth is what Mike says, the final decision is a business decision, not a technical one. You have rules about groups of fields.

To illustrate this once more, look at the case of a stocklevel once more and let's talk about the case with sufficient stock available. There are 100 items and Olaaf and Dennis need 3, you'd still have a conflict, though there is none, if you look at the operation as being a diff update, both can subtract 3 without going out of stock. The traditional simplified conflict detection still would detect a conflict, though there is none. It's a reason there is no general framework about conflict detection, as the rules of thumbs having no problem if different fields are edited are wrong (star/end having a coupling rule are a counter example) and also editing same fields can be a conflict, but isn't necessarily (stock can be deducted by two clerks).

There are ways to avoid locking with diary records, carts, reserving status and surely other mechanisms. All these also profit from all sessions getting instant updates in push notifications, but as much as you like this and as much as it helps, it's a big effort to do so and you also can't rely on this alone becuase there also is a lag of informing all client side sessions. And there is room for misunderstandings: Olaf may think the server by error dedicted his order twice. These mechanism also can work without locking, which I prefer as others prefer databases with no NULLable fierlds.

Optimistic buffering is called optimistic for a reason. It makes the most sense in cases you can be optimistic there are no concurrent changes. Andy Kramek says it's the only buffering mechanism you need, as you also can do RLOCKS yourself and you have the freedom do do them as pessimistic locking at the moment of the first change of a field, or you can do them already at navigation to the record, you have more freedom when you do the lock. So just the side note: Andy Kramek is not saying you should avoid all lock and only handle conflicts as aftermath.

In most of the solutions I talked about the conflicts are also avoided in introducing intermediate states. If a stock is reduced by cart or reservations that change is not yet final, but still signals the availability of other customer sessions starting at that stage, for example, and that does not need the type of live update.

Bye, Olaf.

 

[dkean4]

I did get your point and that of Mike, and then some, Olaf. Great clarity. Thank you.