Client's app performance is dreadfully slow, and I believe the Server is largely responsible. Dealing with a former PITA Corporate tech support team who doesn't know jack squat about VFP and is telling me how it works, especially on the application that I worked on from 2007 to 2010 and was never updated after I left. They probably can't even spell FoxPro. VFP9SP1 application running on client's workstation, using VFP free tables on network share folder managed by Stonefield Database Toolkit. Workstations are Win10 Pro. Server is Windows 2008 Standard. On the server, they've got Windows Defender *AND* an outdated Symantec Endpoint on there that hasn't been updated since 2015 (https://www.screencast.com/t/n5dYLWF0). I also wanted them to add the relevant VFP exclusions in Windows Defender. They said they were there, and I showed here "no they're not." (https://www.screencast.com/t/6vioItlZSuu9)
Corporate "engineering" said this, regarding the slowness: "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB, with the most common used features being the largest. The files are locked, transferred over the network and then updated and written back."
It's the last part especially that has me fueled up to deliver a smack down. Here's what my Draft reply is to my former coworker Tim, who is the Tech who sent me the bullshit answer:
************************ As for this comment (and I'm sure you copied it from the Engineering folks, so I'm not saying that YOU TIM are incorrect): "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB, with the most common used features being the largest. The files are locked, transferred over the network and then updated and written back." -- Tim, the OS has nothing to do with it; 32-bit is fine, and Symplicity won't utilize that much RAM anyway. More important that needs correcting is this Engineering person's understanding of how the Symplicity application and database work; his/her comments about the entire 600MB of files being locked, transferred over the network, then updated and written back are wrong. The Symplicity application is a Visual FoxPro 9.0 SP2 application that uses a File Server database and unlike Access or some other types like that, it does NOT suck over the entire dataset but instead takes the CDX files (which are the index files) to read the relevant data from the network DBFs, only dealing with data requested in the application as needed. Trust me, I know what I'm talking about as you know I fixed the Symplicity application's major bugs from 2007 to 2010, something perhaps your Engineering folks don't know. And it was never updated after I released version 4.0 before I left in 2010. Nobody at your company before or now knows as much about that application and its abilities as I do. That's not arrogance; that's an obvious fact. ************************
So...I am right that the entire 600MB of VFP data files on the network share don't come down over the network, but instead the indexes do, right? I don't even think the DBF comes down--all the "locking" occurs on the file server. I'm betting heavily on this one. Am I right? Was my Access comment right?
(Ok, maybe I was a bit arrogant there, but these dudes need to seriously be corrected.)
tia! --Mike
Mike, You are 100% Correct and in fact the indexes aren't always downloaded in their entirety if Rushmore takes effect as only the major Leaf Nodes need to be interrogated for fully optimised searches.
The DBF header comes down and is locked briefly before being written back for obvious reasons to update the DBF record counts etc. but that is a minor data transfer.
Personally I'd get them to check that the file caching is turned OFF on the server as the default value was to have it turned on in 2008: Device manager/Disk/Properties.
Obviously high tech numpties who think they know it all but actually understand very little!
Dave
--------------------------------------------------------------- This communication and the information it contains is intended for the person or organisation to whom it is addressed. Its contents are confidential and may be protected in law. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the risk of virus transmission through email and therefore any files sent via e-mail will have been checked for known viruses. However, you are advised to run your own virus check before opening any attachments received as Flexipol Packaging Ltd will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate virus protection.
Flexipol Packaging Ltd. Unit 14 Bentwood Road Carrs Industrial Estate Haslingden Rossendale Lancashire BB4 5HH
Tel:01706-222792 Fax: 01706-224683 www.Flexipol.co.uk ---------------------------------------------------------------
Terms & Conditions:
Notwithstanding delivery and the passing of risk in the goods, the property in the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd. ("The Company") has received in cash or cleared funds payment in full of the price of the goods and all other goods agreed to be sold by the seller to the buyer for which payment is then due. Until such time as the property in the goods passes to the buyer, the buyer shall hold the goods as the seller's fiduciary agent and bailee and keep the goods separate from those of the buyer and third parties and properly stored protected and insured and identified as the seller's property but shall be entitled to resell or use the goods in the ordinary course of its business. Until such time as the property in the goods passes to the buyer the seller shall be entitled at any time
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: 01 December 2017 03:55 To: ProFox profox@leafe.com Subject: Check my wording on this and tell me if I'm right
Client's app performance is dreadfully slow, and I believe the Server is largely responsible. Dealing with a former PITA Corporate tech support team who doesn't know jack squat about VFP and is telling me how it works, especially on the application that I worked on from 2007 to 2010 and was never updated after I left. They probably can't even spell FoxPro. VFP9SP1 application running on client's workstation, using VFP free tables on network share folder managed by Stonefield Database Toolkit. Workstations are Win10 Pro. Server is Windows 2008 Standard. On the server, they've got Windows Defender *AND* an outdated Symantec Endpoint on there that hasn't been updated since 2015 (https://www.screencast.com/t/n5dYLWF0). I also wanted them to add the relevant VFP exclusions in Windows Defender. They said they were there, and I showed here "no they're not." (https://www.screencast.com/t/6vioItlZSuu9)
Corporate "engineering" said this, regarding the slowness: "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB, with the most common used features being the largest. The files are locked, transferred over the network and then updated and written back."
It's the last part especially that has me fueled up to deliver a smack down. Here's what my Draft reply is to my former coworker Tim, who is the Tech who sent me the bullshit answer:
************************ As for this comment (and I'm sure you copied it from the Engineering folks, so I'm not saying that YOU TIM are incorrect): "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB, with the most common used features being the largest. The files are locked, transferred over the network and then updated and written back." -- Tim, the OS has nothing to do with it; 32-bit is fine, and Symplicity won't utilize that much RAM anyway. More important that needs correcting is this Engineering person's understanding of how the Symplicity application and database work; his/her comments about the entire 600MB of files being locked, transferred over the network, then updated and written back are wrong. The Symplicity application is a Visual FoxPro 9.0 SP2 application that uses a File Server database and unlike Access or some other types like that, it does NOT suck over the entire dataset but instead takes the CDX files (which are the index files) to read the relevant data from the network DBFs, only dealing with data requested in the application as needed. Trust me, I know what I'm talking about as you know I fixed the Symplicity application's major bugs from 2007 to 2010, something perhaps your Engineering folks don't know. And it was never updated after I released version 4.0 before I left in 2010. Nobody at your company before or now knows as much about that application and its abilities as I do. That's not arrogance; that's an obvious fact. ************************
So...I am right that the entire 600MB of VFP data files on the network share don't come down over the network, but instead the indexes do, right? I don't even think the DBF comes down--all the "locking" occurs on the file server. I'm betting heavily on this one. Am I right? Was my Access comment right?
(Ok, maybe I was a bit arrogant there, but these dudes need to seriously be corrected.)
tia! --Mike
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/0f5f01946951bef6a017ffda95db7379@mbso... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Hi Mike,
Just to be clear: If you didn't adhere to the Rushmore-optimization topics then they are correct, as this will definitely bring down the whole table to the client, if VFP has to do a full-table-scan to find a record. Also any "REPLACE ALL ..." will do the same, since data-processing is always at client-side. Thus you'd better check your coding twice :)
Then for optimization, there are two things to check: a) Network-speed, b) Server-Speed
a) Network-Speed in our case is depending on the use of SMB1 or SMB2/SMB3. SMB1 is used in WinXP/Server2003, SMB2 is Vista and S2008, SMB2.1 is Win7 and S2008/R2, SMB3 is Win8 and S2012, SMB3.1 is Win10 and S2016. SMB1 was a block-based transfer, whereas starting with SMB2 it got a stream-based transport. Even if you could take the easy way out and disable SMB2/3 either on server or client side, it's not a valuable recommendation, since modern Windows technologies are depending on those additional features of the newer standard. You better live with those. http://support.microsoft.com/kb/2696547
The effect which Tracy mentioned (single network user is faster than multiple users), is only partly related to that topic, but mostly with the dreaded Opportunistic Locking (or short "OpLock", which corrupts our CDX and data). SMB2/3 (as a streaming protocol) holds a local buffer to accomodate datastreams as well as OppLocks. The common solution is to disable that caching, which effectively kills the OpLocks problem. For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
-------------------------------------- b) Then there are several tweaks at the server level. Unfortunately there are a lot of Hotfixes for Server 2008, 2008/R2, 2012 and 2012/R2, which are all related to those SMB and network problems. Thus you need those Admins to cooperate, if they want to make their users happy, as they need to get their server patched.
See here for Server 2008: https://support.microsoft.com/en-us/help/2473205/list-of-currently-available -hotfixes-for-the-file-services-technologie See here for Server 2012: https://support.microsoft.com/en-us/help/2899011/list-of-currently-available -hotfixes-for-the-file-services-technologie
-------------------------------------- Besides of those Hotfixes there are three more settings: FairShare, SMB Signing and SMB Secure Negotiaton (if data resides on a NAS). Here are some links for How-To: http://www.ryslander.com/disable-fair-sharing-in-windows-server/ http://mctexpert.blogspot.de/2011/02/disable-smb-signing.html https://support.microsoft.com/en-us/help/2686098/-system-error-2148073478--e xtended-error--or-invalid-signature-error-m
Also, if that dataserver is actually a HyperV hosted maschine, it should be a Gen1 Machine, not a Gen2 (the file-extension should be *.VHD, not *.VHDX). http://itgroove.net/thebeagle/2014/07/30/hyper-v-hellsort-of/
P.S. If you wonder why I have all those infos available, I just had a session about that stuff at the german DevCon. See, you should have gone there! <g>
wOOdy
"*´¨) ¸.·´¸.·*´¨) ¸.·*¨) (¸.·´. (¸.·` * .·`.Visual FoxPro: It's magic ! (¸.·``··*
The slowness is almost certainly caused by running Symantec and Windows Defender on the server. There's almost no reason to run realtime A/V on a server, IMO. All files must go through a workstation, so that's the first line of defense.
Eric
On Fri, Dec 1, 2017 at 7:15 AM, Jürgen Wondzinski juergen@wondzinski.de wrote:
Hi Mike,
Just to be clear: If you didn't adhere to the Rushmore-optimization topics then they are correct, as this will definitely bring down the whole table to the client, if VFP has to do a full-table-scan to find a record. Also any "REPLACE ALL ..." will do the same, since data-processing is always at client-side. Thus you'd better check your coding twice :)
Then for optimization, there are two things to check: a) Network-speed, b) Server-Speed
a) Network-Speed in our case is depending on the use of SMB1 or SMB2/SMB3. SMB1 is used in WinXP/Server2003, SMB2 is Vista and S2008, SMB2.1 is Win7 and S2008/R2, SMB3 is Win8 and S2012, SMB3.1 is Win10 and S2016. SMB1 was a block-based transfer, whereas starting with SMB2 it got a stream-based transport. Even if you could take the easy way out and disable SMB2/3 either on server or client side, it's not a valuable recommendation, since modern Windows technologies are depending on those additional features of the newer standard. You better live with those. http://support.microsoft.com/kb/2696547
The effect which Tracy mentioned (single network user is faster than multiple users), is only partly related to that topic, but mostly with the dreaded Opportunistic Locking (or short "OpLock", which corrupts our CDX and data). SMB2/3 (as a streaming protocol) holds a local buffer to accomodate datastreams as well as OppLocks. The common solution is to disable that caching, which effectively kills the OpLocks problem. For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
b) Then there are several tweaks at the server level. Unfortunately there are a lot of Hotfixes for Server 2008, 2008/R2, 2012 and 2012/R2, which are all related to those SMB and network problems. Thus you need those Admins to cooperate, if they want to make their users happy, as they need to get their server patched.
See here for Server 2008: https://support.microsoft.com/en-us/help/2473205/list-of- currently-available -hotfixes-for-the-file-services-technologie See here for Server 2012: https://support.microsoft.com/en-us/help/2899011/list-of- currently-available -hotfixes-for-the-file-services-technologie
Besides of those Hotfixes there are three more settings: FairShare, SMB Signing and SMB Secure Negotiaton (if data resides on a NAS). Here are some links for How-To: http://www.ryslander.com/disable-fair-sharing-in-windows-server/ http://mctexpert.blogspot.de/2011/02/disable-smb-signing.html https://support.microsoft.com/en-us/help/2686098/-system- error-2148073478--e xtended-error--or-invalid-signature-error-m
Also, if that dataserver is actually a HyperV hosted maschine, it should be a Gen1 Machine, not a Gen2 (the file-extension should be *.VHD, not *.VHDX). http://itgroove.net/thebeagle/2014/07/30/hyper-v-hellsort-of/
P.S. If you wonder why I have all those infos available, I just had a session about that stuff at the german DevCon. See, you should have gone there! <g>
wOOdy
"*´¨) ¸.·´¸.·*´¨) ¸.·*¨) (¸.·´. (¸.·` * .·`.Visual FoxPro: It's magic ! (¸.·``··*
[excessive quoting removed by server]
There's definitely no reason to be running TWO realtime AV on *any* machine.
On 2017-12-01 11:24, Alan Bourke wrote:
There's definitely no reason to be running TWO realtime AV on *any* machine.
Exactly. I can't believe I'm seeing something like this. It's so stupid, imho. Nothing says "I don't know what I'm doing" like running 2 of these systems on one machine.
On 2017-12-01 09:29, Eric Selje wrote:
The slowness is almost certainly caused by running Symantec and Windows Defender on the server. There's almost no reason to run realtime A/V on a server, IMO. All files must go through a workstation, so that's the first line of defense.
My thoughts EXACTLY but the Corporate staff thinks they know best.
That is a corporate rule everywhere I have worked for the past 20 years.
From their POV why should I endanger any asset in the network?
On Fri, Dec 1, 2017 at 10:53 AM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2017-12-01 09:29, Eric Selje wrote:
The slowness is almost certainly caused by running Symantec and Windows Defender on the server. There's almost no reason to run realtime A/V on a server, IMO. All files must go through a workstation, so that's the first line of defense.
My thoughts EXACTLY but the Corporate staff thinks they know best.
[excessive quoting removed by server]
Ah, the old "Why do we cut the end off the roast?" rule.
On Fri, Dec 1, 2017 at 11:06 AM, Stephen Russell srussell705@gmail.com wrote:
That is a corporate rule everywhere I have worked for the past 20 years.
From their POV why should I endanger any asset in the network?
On Fri, Dec 1, 2017 at 10:53 AM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 2017-12-01 09:29, Eric Selje wrote:
The slowness is almost certainly caused by running Symantec and Windows Defender on the server. There's almost no reason to run realtime A/V on
a
server, IMO. All files must go through a workstation, so that's the
first
line of defense.
My thoughts EXACTLY but the Corporate staff thinks they know best.
[excessive quoting removed by server]
On 2017-12-01 08:15, Jürgen Wondzinski wrote:
Hi Mike,
Just to be clear: If you didn't adhere to the Rushmore-optimization topics then they are correct, as this will definitely bring down the whole table to the client, if VFP has to do a full-table-scan to find a record. Also any "REPLACE ALL ..." will do the same, since data-processing is always at client-side. Thus you'd better check your coding twice :)
Well, unfortunately, my code is only a fraction of this app. I did get a lot of the problems fixed (and as a result, that's why it's still running and hasn't been replaced over 8 years now after I released the last version (they still use it!); however, I do know the legacy code has a lot of REPLACE ALL commands, so perhaps that's why so much of it is coming down the pike then. Damn. I really wanted to slam-dunk this one.
Then for optimization, there are two things to check: a) Network-speed, b) Server-Speed
They're using Windows Server 2008. I don't know of any plans to update it. Ugh
a) Network-Speed in our case is depending on the use of SMB1 or SMB2/SMB3. SMB1 is used in WinXP/Server2003, SMB2 is Vista and S2008, SMB2.1 is Win7 and S2008/R2, SMB3 is Win8 and S2012, SMB3.1 is Win10 and S2016. SMB1 was a block-based transfer, whereas starting with SMB2 it got a stream-based transport. Even if you could take the easy way out and disable SMB2/3 either on server or client side, it's not a valuable recommendation, since modern Windows technologies are depending on those additional features of the newer standard. You better live with those. http://support.microsoft.com/kb/2696547
This Server is Corporate's responsibility and I cannot alter the policies on it. :/
The effect which Tracy mentioned (single network user is faster than multiple users), is only partly related to that topic, but mostly with the dreaded Opportunistic Locking (or short "OpLock", which corrupts our CDX and data). SMB2/3 (as a streaming protocol) holds a local buffer to accomodate datastreams as well as OppLocks. The common solution is to disable that caching, which effectively kills the OpLocks problem. For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
I recall turning off write-behind caching on the local drive. In reading that M$ article, it doesn't sound like that the same thing?
b) Then there are several tweaks at the server level. Unfortunately there are a lot of Hotfixes for Server 2008, 2008/R2, 2012 and 2012/R2, which are all related to those SMB and network problems. Thus you need those Admins to cooperate, if they want to make their users happy, as they need to get their server patched.
See here for Server 2008: https://support.microsoft.com/en-us/help/2473205/list-of-currently-available -hotfixes-for-the-file-services-technologie See here for Server 2012: https://support.microsoft.com/en-us/help/2899011/list-of-currently-available -hotfixes-for-the-file-services-technologie
Long story short: it'd be a waste of my breath, is my bet.
Besides of those Hotfixes there are three more settings: FairShare, SMB Signing and SMB Secure Negotiaton (if data resides on a NAS). Here are some links for How-To: http://www.ryslander.com/disable-fair-sharing-in-windows-server/ http://mctexpert.blogspot.de/2011/02/disable-smb-signing.html https://support.microsoft.com/en-us/help/2686098/-system-error-2148073478--e xtended-error--or-invalid-signature-error-m
Also, if that dataserver is actually a HyperV hosted maschine, it should be a Gen1 Machine, not a Gen2 (the file-extension should be *.VHD, not *.VHDX). http://itgroove.net/thebeagle/2014/07/30/hyper-v-hellsort-of/
P.S. If you wonder why I have all those infos available, I just had a session about that stuff at the german DevCon. See, you should have gone there!
<g>
That would have been fun, I'm sure!
Thanks!
On 2017-12-01 08:15, Jürgen Wondzinski wrote:
The effect which Tracy mentioned (single network user is faster than multiple users), is only partly related to that topic, but mostly with the dreaded Opportunistic Locking (or short "OpLock", which corrupts our CDX and data). SMB2/3 (as a streaming protocol) holds a local buffer to accomodate datastreams as well as OppLocks. The common solution is to disable that caching, which effectively kills the OpLocks problem. For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
Hi wOOdy,
See here: https://www.screencast.com/t/4tEaNq72
I don't see those 3 different settings (DirectoryCacheLifetime, FileNotFoundCacheLifetime, and FileInfoCacheLifetime) at all. Plus, the middle column in the M$ page--those values all look the same: https://www.screencast.com/t/EErMmZ4z6r
I'm confused?
Hi Mike,
I'm confused?
Yes you are. :)
First: The MS information. Use the horizontal slider bar at the bottom of the table listing to scroll to the left. The first column lists the Keys. The third column is the "Parent", the folder where those keys are. (Those tables are standardized format at MS documentation, and it could well be that several registry keys are in different places, thus the third column would then show different valus. In our case they are all at the same tree-node)
Second: If those keys aren't present, then their internal default is used. But if they are present, then they take precedence over the defaults. Thus just add those keys and life is good. Or use the mentioned installer to see those Keys and their Values to magically show up. The installer just adds those three keys, and has the benefit to do a simple uninstall (thus reverting them back), if you're later on don't deed those settings anymore (because you changed to a ODBC/OLEDB dataprovider)
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox [mailto:profox-bounces@leafe.com] Im Auftrag von mbsoftwaresolutions@mbsoftwaresolutions.com Gesendet: Freitag, 8. Dezember 2017 05:11 An: ProFox Email List profox@leafe.com Betreff: Re: AW: Check my wording on this and tell me if I'm right
On 2017-12-01 08:15, Jürgen Wondzinski wrote:
The effect which Tracy mentioned (single network user is faster than multiple users), is only partly related to that topic, but mostly with the dreaded Opportunistic Locking (or short "OpLock", which corrupts our CDX and data). SMB2/3 (as a streaming protocol) holds a local buffer to accomodate datastreams as well as OppLocks. The common solution is to disable that caching, which effectively kills the OpLocks problem. For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
Hi wOOdy,
See here: https://www.screencast.com/t/4tEaNq72
I don't see those 3 different settings (DirectoryCacheLifetime, FileNotFoundCacheLifetime, and FileInfoCacheLifetime) at all. Plus, the middle column in the M$ page--those values all look the same: https://www.screencast.com/t/EErMmZ4z6r
I'm confused?
[excessive quoting removed by server]
I had a question about how a statement could get slow response times in the past. Christof gave a long explanation about client and server cache. One person connected to the table the program is fast. Get a second person and the program gets real slow. I'll try to search for it later.
Tracy
On November 30, 2017 10:54:38 PM EST, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Client's app performance is dreadfully slow, and I believe the Server is largely responsible. Dealing with a former PITA Corporate tech support
team who doesn't know jack squat about VFP and is telling me how it works, especially on the application that I worked on from 2007 to 2010
and was never updated after I left. They probably can't even spell FoxPro. VFP9SP1 application running on client's workstation, using VFP
free tables on network share folder managed by Stonefield Database Toolkit. Workstations are Win10 Pro. Server is Windows 2008 Standard.
On the server, they've got Windows Defender *AND* an outdated Symantec Endpoint on there that hasn't been updated since 2015 (https://www.screencast.com/t/n5dYLWF0). I also wanted them to add the
relevant VFP exclusions in Windows Defender. They said they were there, and I showed here "no they're not." (https://www.screencast.com/t/6vioItlZSuu9)
Corporate "engineering" said this, regarding the slowness: "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost
600MB, with the most common used features being the largest. The files
are locked, transferred over the network and then updated and written back."
It's the last part especially that has me fueled up to deliver a smack down. Here's what my Draft reply is to my former coworker Tim, who is the Tech who sent me the bullshit answer:
As for this comment (and I'm sure you copied it from the Engineering folks, so I'm not saying that YOU TIM are incorrect): "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB, with the most common used features being the largest. The files are locked, transferred over the network and then updated and written back." -- Tim, the OS has nothing to do with it; 32-bit is fine, and Symplicity won't utilize that much RAM anyway. More important that needs correcting is this Engineering person's understanding of how the Symplicity application and database work; his/her comments about the entire 600MB of files being locked, transferred over the network, then updated and written back are wrong. The Symplicity application is a Visual FoxPro 9.0 SP2 application that uses a File Server database and unlike Access or some other types like that, it does NOT suck over the entire dataset but instead takes the CDX files (which are the index files) to read the relevant data from the network DBFs, only dealing with data requested in the application as needed. Trust me, I know what I'm talking about as you know I fixed the Symplicity application's major bugs from 2007 to 2010, something perhaps your Engineering folks don't know. And it was never updated after I released version 4.0 before I left in 2010. Nobody at your company before or now knows as much about
that application and its abilities as I do. That's not arrogance; that's an obvious fact.
So...I am right that the entire 600MB of VFP data files on the network share don't come down over the network, but instead the indexes do, right? I don't even think the DBF comes down--all the "locking" occurs
on the file server. I'm betting heavily on this one. Am I right? Was
my Access comment right?
(Ok, maybe I was a bit arrogant there, but these dudes need to seriously be corrected.)
tia! --Mike
[excessive quoting removed by server]
Tracy,
that's the old OpLocks settings, not sure if they are relevant in Win 10 and Server 2008 (I haven't used DBFs in a long time).
Mike, I can provide the registry settings that you need to fiddle with if that is the problem.
Frank.
Frank Cazabon
On 01/12/2017 08:10 AM, Tracy Pearson wrote:
I had a question about how a statement could get slow response times in the past. Christof gave a long explanation about client and server cache. One person connected to the table the program is fast. Get a second person and the program gets real slow. I'll try to search for it later.
Tracy
On November 30, 2017 10:54:38 PM EST, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Client's app performance is dreadfully slow, and I believe the Server is largely responsible. Dealing with a former PITA Corporate tech support
team who doesn't know jack squat about VFP and is telling me how it works, especially on the application that I worked on from 2007 to 2010
and was never updated after I left. They probably can't even spell FoxPro. VFP9SP1 application running on client's workstation, using VFP
free tables on network share folder managed by Stonefield Database Toolkit. Workstations are Win10 Pro. Server is Windows 2008 Standard.
On the server, they've got Windows Defender *AND* an outdated Symantec Endpoint on there that hasn't been updated since 2015 (https://www.screencast.com/t/n5dYLWF0). I also wanted them to add the
relevant VFP exclusions in Windows Defender. They said they were there, and I showed here "no they're not." (https://www.screencast.com/t/6vioItlZSuu9)
Corporate "engineering" said this, regarding the slowness: "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost
600MB, with the most common used features being the largest. The files
are locked, transferred over the network and then updated and written back."
It's the last part especially that has me fueled up to deliver a smack down. Here's what my Draft reply is to my former coworker Tim, who is the Tech who sent me the bullshit answer:
As for this comment (and I'm sure you copied it from the Engineering folks, so I'm not saying that YOU TIM are incorrect): "It's a 32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB, with the most common used features being the largest. The files are locked, transferred over the network and then updated and written back." -- Tim, the OS has nothing to do with it; 32-bit is fine, and Symplicity won't utilize that much RAM anyway. More important that needs correcting is this Engineering person's understanding of how the Symplicity application and database work; his/her comments about the entire 600MB of files being locked, transferred over the network, then updated and written back are wrong. The Symplicity application is a Visual FoxPro 9.0 SP2 application that uses a File Server database and unlike Access or some other types like that, it does NOT suck over the entire dataset but instead takes the CDX files (which are the index files) to read the relevant data from the network DBFs, only dealing with data requested in the application as needed. Trust me, I know what I'm talking about as you know I fixed the Symplicity application's major bugs from 2007 to 2010, something perhaps your Engineering folks don't know. And it was never updated after I released version 4.0 before I left in 2010. Nobody at your company before or now knows as much about
that application and its abilities as I do. That's not arrogance; that's an obvious fact.
So...I am right that the entire 600MB of VFP data files on the network share don't come down over the network, but instead the indexes do, right? I don't even think the DBF comes down--all the "locking" occurs
on the file server. I'm betting heavily on this one. Am I right? Was
my Access comment right?
(Ok, maybe I was a bit arrogant there, but these dudes need to seriously be corrected.)
tia! --Mike
[excessive quoting removed by server]
On 2017-12-01 08:12, Frank Cazabon wrote:
Tracy,
that's the old OpLocks settings, not sure if they are relevant in Win 10 and Server 2008 (I haven't used DBFs in a long time).
Mike, I can provide the registry settings that you need to fiddle with if that is the problem.
Frank.
Frank Cazabon
Registry settings for the Server? I can't change those. That's Corporate area of responsibility. For me to do that, it'd be like "crossing the streams" as far as they're concerned. lol
On 2017-12-01 13:43, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2017-12-01 08:12, Frank Cazabon wrote:
Tracy,
that's the old OpLocks settings, not sure if they are relevant in Win 10 and Server 2008 (I haven't used DBFs in a long time).
Mike, I can provide the registry settings that you need to fiddle with if that is the problem.
Frank.
Frank Cazabon
Registry settings for the Server? I can't change those. That's Corporate area of responsibility. For me to do that, it'd be like "crossing the streams" as far as they're concerned. lol
Oh wait...in reading wOOdy's post again, I think you meant local as he said, right?
For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
Yes, Frank, please send them to me. Thanks!
On 2017-12-01 13:46, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Oh wait...in reading wOOdy's post again, I think you meant local as he said, right?
For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
Yes, Frank, please send them to me. Thanks!
Is it these, Frank? https://www.screencast.com/t/WgjD8f1gwWF
No, those might be for handling the SMB2 issue. I sent an email with the parameters you need to change, which you've probably seen by now :)
Frank.
Frank Cazabon
On 01/12/2017 02:48 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2017-12-01 13:46, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Oh wait...in reading wOOdy's post again, I think you meant local as he said, right?
For that you have to set three Registry Keys at the CLIENT, nothing to do at server side. You can/should check for correct settings in your app at startup, but you (normally) can't change those settings on the fly, since you need Admin Rights for that. (Thus you'd better package those into your installer) https://technet.microsoft.com/en-us/library/ff686200%28WS.10%29.aspx
Yes, Frank, please send them to me. Thanks!
Is it these, Frank? https://www.screencast.com/t/WgjD8f1gwWF
[excessive quoting removed by server]
On 01/12/2017 02:43 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2017-12-01 08:12, Frank Cazabon wrote:
Tracy,
that's the old OpLocks settings, not sure if they are relevant in Win 10 and Server 2008 (I haven't used DBFs in a long time).
Mike, I can provide the registry settings that you need to fiddle with if that is the problem.
Frank.
Frank Cazabon
Registry settings for the Server? I can't change those. That's Corporate area of responsibility. For me to do that, it'd be like "crossing the streams" as far as they're concerned. lol
LOL, I can't remember, but here are the instructions I have used in the past, a quick read doesn't seem to imply it has to be done on the server, but not sure:
1. Set OPLocks off for increased speed in multiuser systems
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\
set OplocksDisabled = 1
OplocksDisabled REG_DWORD 0 or 1 Default: 0 (not disabled)
2. HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
SharingViolationRetries REG_DWORD 0?1000 attempts
Default: 5
Determines the maximum number of times the Server service attempts a file operation when the file system responds with a sharing violation error. If a client requests more attempts that the value of this entry allows, the Server service returns an error. This value entry applies to open, rename, and delete operations.
Note
Windows NT does not add this value to the Registry. You can add it by editing the Registry or by using a program that edits the Registry.
SharingViolationDelay REG_DWORD 0?1000 milliseconds
Default: 200
Determines the time interval between repeated requests for a file operation when the file system responds with a sharing violation error. This value entry applies to open, rename, and delete operations. Decreasing this value (requesting more frequently) increases network traffic. However, increasing this value (requesting less frequently) might delay users unnecesarily.
Note
Windows NT does not add this value to the Registry. You can add it by editing the Registry or by using a program that edits the Registry.
[excessive quoting removed by server]
On 2017-12-01 13:53, Frank Cazabon wrote:
Registry settings for the Server? I can't change those. That's Corporate area of responsibility. For me to do that, it'd be like "crossing the streams" as far as they're concerned. lol
LOL, I can't remember, but here are the instructions I have used in the past, a quick read doesn't seem to imply it has to be done on the server, but not sure:
- Set OPLocks off for increased speed in multiuser systems
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\
set OplocksDisabled = 1
OplocksDisabled REG_DWORD 0 or 1 Default: 0 (not disabled)
Must be on the Server. Checked the client's Win10Pro workstation and didn't see OplocksDisabled in the Registry. I can't change their Server settings.
My notes are from quite a few years ago, maybe it is no longer created by default. Maybe you could try creating it and see if it makes a difference
On 5 December 2017 21:21:18 GMT-04:00, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2017-12-01 13:53, Frank Cazabon wrote:
Registry settings for the Server? I can't change those. That's Corporate area of responsibility. For me to do that, it'd be like "crossing the streams" as far as they're concerned. lol
LOL, I can't remember, but here are the instructions I have used in the past, a quick read doesn't seem to imply it has to be done on the server, but not sure:
- Set OPLocks off for increased speed in multiuser systems
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\
set OplocksDisabled = 1
OplocksDisabled REG_DWORD 0 or 1 Default: 0 (not disabled)
Must be on the Server. Checked the client's Win10Pro workstation and didn't see OplocksDisabled in the Registry. I can't change their Server settings.
[excessive quoting removed by server]
Why not just use my provided link to the three RegKeys needed? And yes: you don't mess with the server, the caching is at the client.
wOOdy
If you're having problems with changing/adding three RegKeys, you also could use the Tool from Alaska Software http://www.alaska-software.com/community/smb2.cxp, which points to https://www.alaska-software.com/download-center/main.cxp
You need to create an account for the download though. If you don't want to, then you could also find it here: https://www.dropbox.com/s/aa9vwwup1u8h2zy/OPLock_Set_SMB2-infocache.msi?dl=0
wOOdy
On 2017-12-06 04:17, Jürgen Wondzinski wrote:
If you're having problems with changing/adding three RegKeys, you also could use the Tool from Alaska Software http://www.alaska-software.com/community/smb2.cxp, which points to https://www.alaska-software.com/download-center/main.cxp
You need to create an account for the download though. If you don't want to, then you could also find it here: https://www.dropbox.com/s/aa9vwwup1u8h2zy/OPLock_Set_SMB2-infocache.msi?dl=0
wOOdy
Thanks, wOOdy! I'll try this tonight from the home office and advise.
-
Alan Bourke -
Dave Crozier -
Eric Selje -
Frank Cazabon -
Jürgen Wondzinski -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Stephen Russell -
Tracy Pearson