Hopefully Olaf or the other experts can offer their opinion on this. Quick background: I took over an unfinished VFP 9 program and did some fairly minor modifications. The program apparently could (in the past) work well with several users at once. Now when a 2nd user opens the program both experience terrible lag times before reports are displayed, etc. With one user, no problem. Yesterday I logged in remotely using LogMeIn and took the role of the 2nd person. I did not experience any lag times, reports opened quickly, buttons responded instantly. I had the 'local' user click on the same buttons at the same time and her reports always took 5 seconds or more than me to come up. When a 3rd person opened the program, I still experienced no delays, whereas the situation became even worse for the both of them. So what does that indicate? I would think if the program was at fault I would have also seen delays, and perhaps moreso being logged on remotely. Two issues of note: the owner informed me today that their users are wireless ; the network guy (who I don't think is that sharp) mentioned he "re-built the server" a while ago. If this is likely a network issue, what types of issues cause a big performance drop when simply one additional user is in a program?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
slow multi-user behavior: Network problem or program ?
- Thread starter jamesrav
- Start date
Olaf Doschke
Programmer
That describes what oplocks do. It doesn't matter whether the first user is remote or local, not even if he's the first user logged in in the application, just the first user of the DBF.
The latest question on this was here: thread184-1792486
Bye, Olaf.
Olaf Doschke Software Engineering
The latest question on this was here: thread184-1792486
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #3
thank you Olaf. Your reply seems to imply that one user will still experience good response times if he/she was 1st in using a DBF. But what they are describing to me is that as soon as a 2nd person opens the program and begins to interact with the tables, both users experience a slow down. If it was this oplock issue, should that happen? When I was logged on remotely I never experienced a slowdown, and I'm pretty sure at some point I had to be 'second' when accessing the most used table.
Your post in that thread mentions some things to do (registry, etc) but I couldn't tell if they were specific to his problem(mapped drives being ignored) or helped for oplock problems in general. If I log in remotely and the other person does as well, if it's an oplock problem then somebody should see performance suffer? If neither do, then it's not an oplock issue?
Your post in that thread mentions some things to do (registry, etc) but I couldn't tell if they were specific to his problem(mapped drives being ignored) or helped for oplock problems in general. If I log in remotely and the other person does as well, if it's an oplock problem then somebody should see performance suffer? If neither do, then it's not an oplock issue?
Ops locks are a strange thing.
What tends to happen is that the first user asks to open the file (particularly true for small files for some reason) in a shared mode, and the server thinks it's clever to actually open it in an exclusive mode.
The second user tries to open the file in shared mode and then the server is supposed to negotiate with the first user and release the lock and away the two users go, but that release is not well implemented and sometimes doesn't happen and things get jammed up until the first guy lets go of the file and the second user gets it - if the server then gives it to them as shared things get better, but again the implementation is poor and the whole thing is a mess.
By far the best thing is to get the files on a server that doesn't support ops locks, a NAS drive or a Linux box, or you have to try and turn them off on the server, which is not so easy these days.
Regards
Griff
Keep [Smile]ing
What tends to happen is that the first user asks to open the file (particularly true for small files for some reason) in a shared mode, and the server thinks it's clever to actually open it in an exclusive mode.
The second user tries to open the file in shared mode and then the server is supposed to negotiate with the first user and release the lock and away the two users go, but that release is not well implemented and sometimes doesn't happen and things get jammed up until the first guy lets go of the file and the second user gets it - if the server then gives it to them as shared things get better, but again the implementation is poor and the whole thing is a mess.
By far the best thing is to get the files on a server that doesn't support ops locks, a NAS drive or a Linux box, or you have to try and turn them off on the server, which is not so easy these days.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
The perhaps easiest way to fix the problem is letting users use the program through Remote Desktop connections. the application and DBF files can then be installed on one server, you have no networked data access, the network merely is doing the remote connections.
Wifi has turned out to be bad for SQL Server usage. You make your connection getting an integer connection handle, you make your SQLExecs of whatever and that integer handle should suffice to keep the connection, but when your requests come from differnt SPIDs SQL Server may rejects them. Something like that was going on. I wasn't informed of the full result of that tests, it was just a case in a bigger corporation having wifi endpoints in every floor of a building and users might glitch from the endpoint of their floor into the ones from the floor below or above. They retried later, so they lost that knowledge, I'd say, they may have tried binding devices to a certain endpoint, it still didn't work, but this handle connection thing isn't happening with DBFs.
You have other handles to the file system than to SQL Server.
Bye, Olaf
Olaf Doschke Software Engineering
Wifi has turned out to be bad for SQL Server usage. You make your connection getting an integer connection handle, you make your SQLExecs of whatever and that integer handle should suffice to keep the connection, but when your requests come from differnt SPIDs SQL Server may rejects them. Something like that was going on. I wasn't informed of the full result of that tests, it was just a case in a bigger corporation having wifi endpoints in every floor of a building and users might glitch from the endpoint of their floor into the ones from the floor below or above. They retried later, so they lost that knowledge, I'd say, they may have tried binding devices to a certain endpoint, it still didn't work, but this handle connection thing isn't happening with DBFs.
You have other handles to the file system than to SQL Server.
Bye, Olaf
Olaf Doschke Software Engineering
Mike Lewis
Programmer
This is indeed a good solution - at least, if your data is in DBF files or another "desktop" database. A system I once worked on was slowing down considerably as the number of users increased. The hardware guy decided to try moving the data to a NAS drive. It was an instant success. The speed-up was dramatic, with all the delays disappearing.
I'm not sure whether that would be a good solution for a client-server database such as SQL Server, where oplocks are more beneficial (somebody will correct me if I am wrong about that).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Olaf Doschke
Programmer
Mike,
I don't have experience with NAS, most modern will likely also do oplocks, but many of them are Linux based and implement the Windows network protocol on SAMBA (derived from SMB) and in many ways that seems to be a better implementation than Windows own. Besides, you likely have it easier to configure how SAMBA acts as the network server component and might simpler opt to turn off that mechanism. For any data, it's best only cached in reading direction, but the DBF file updates as soon as possible, aka write-through caching. That is also what routers should be configured to aside of ideally not needing to negotiate network bandwidth 10/100/1000/10000 MBit but know the neighboring or all network supports 1GBit or 10Gbit.
Regarding SQL Server, the file access it does is on it's local MDF/LDF Files, maybe even just a single pair of files for a database not using multiple partitions and file sets. And since that file access is local, SMB and oplocks play no role for SQL Servers, that's why changing an application to work with a SQL Server backend (or others) also is a way out of the oplocks problem, it's just not as fast as setgin up a NAS or Remote Desktop usage of a software.
Bye, Olaf.
Olaf Doschke Software Engineering
I don't have experience with NAS, most modern will likely also do oplocks, but many of them are Linux based and implement the Windows network protocol on SAMBA (derived from SMB) and in many ways that seems to be a better implementation than Windows own. Besides, you likely have it easier to configure how SAMBA acts as the network server component and might simpler opt to turn off that mechanism. For any data, it's best only cached in reading direction, but the DBF file updates as soon as possible, aka write-through caching. That is also what routers should be configured to aside of ideally not needing to negotiate network bandwidth 10/100/1000/10000 MBit but know the neighboring or all network supports 1GBit or 10Gbit.
Regarding SQL Server, the file access it does is on it's local MDF/LDF Files, maybe even just a single pair of files for a database not using multiple partitions and file sets. And since that file access is local, SMB and oplocks play no role for SQL Servers, that's why changing an application to work with a SQL Server backend (or others) also is a way out of the oplocks problem, it's just not as fast as setgin up a NAS or Remote Desktop usage of a software.
Bye, Olaf.
Olaf Doschke Software Engineering
Mike Lewis
Programmer
Thanks for that, Olaf. I wasn't sure if it was the oplocks issue that caused the speedup with the NAS drive. But the speedup certainly was dramatic. I don't know what OS or network protocols the NAS used. Of course, we tested it thoroughly, and saw that all the file and record locking within VFP was working correctly.
Regarding SQL Server, my understanding is that disabling oplocks could worsen performance with client-server databases, but I'm realy not sure about any of this.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Regarding SQL Server, my understanding is that disabling oplocks could worsen performance with client-server databases, but I'm realy not sure about any of this.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
If I remember my history correctly, OpLocks were a Microsoft fiddle to get around the poor performance of their networking products back in the day - when they were competing with 'real' server systems such as Netware and Unix and only had a fairly rudimentary product themselves.
Op locks enabled them to appear a tiny bit faster because most network testing at the time was either file copying based, dragging hundreds of files from a server or essentially single user - their being relatively few multi-user database products about that you could automate for testing - dBaseII? days again.
Regards
Griff
Keep [Smile]ing
Op locks enabled them to appear a tiny bit faster because most network testing at the time was either file copying based, dragging hundreds of files from a server or essentially single user - their being relatively few multi-user database products about that you could automate for testing - dBaseII? days again.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
Asoplocks is actually a caching mechanism preventing write through (or write back of changes a client made on a file), unless the server sees another client asking for that file, I don't see how that would affect an SQL Server database. SMB protocol is about file access, not any network traffic. And your observation record locks work also has nothing to do with oplocks.
Queries to database servers aren't file-requests, only the SQL Server acts on data files, the rest is just TCP/IP communication (and on localhost servers, you may also communicate with shared memory protocol).
So oplocks neither accelerate nor decelerate any file access. You would need to talk about a SAN where servers are clusters and data is distributed. I just doubt a Foxpro client or Access or other such clients ever is a client to such a large database cluster.
At least not when it organically grows starting from DBFs later migrated into a server database, you'll not even have a simple two server cluster.
Bye, Olaf.
Olaf Doschke Software Engineering
Queries to database servers aren't file-requests, only the SQL Server acts on data files, the rest is just TCP/IP communication (and on localhost servers, you may also communicate with shared memory protocol).
So oplocks neither accelerate nor decelerate any file access. You would need to talk about a SAN where servers are clusters and data is distributed. I just doubt a Foxpro client or Access or other such clients ever is a client to such a large database cluster.
At least not when it organically grows starting from DBFs later migrated into a server database, you'll not even have a simple two server cluster.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #12
I like Olaf's solution of using RD to connect (multiple) users, which gets around this apparent Oplock issue. And certainly it should be easy to automatically open the Foxpro program upon connection. The final issue would be making sure the user is forced off the RD connection (and therefore the server) when they close the Foxpro program (sidebar: I imagine it's possible to restrict the user's activity once logged on, meaning they can't do any nosing around / damage while on the server). Can that be accomplished thru group policy settings, or can the Foxpro program itself force a disconnect of RD when it is closed? I would like the latter since it's some programming work 
.
.
Olaf Doschke
Programmer
You should ask a RD/RDP expert. The DEvOps dep<rtment of companies usually handle how users access the terminal servers and you can not only use mstsc.exe to connect to a remote session and seeing itsdesktop, then starting an app, you can start a remote session and the application itself. Not sue you can have seamless experience like seeing that application only on your own desktop as if it executed locally and ending it also closes the RD session. That's something working and descriobed to be that way with VMWare.
It might not work out that well when your VFP application for example uses GETFILE() and a dialog appears, which potentially does not need to be in the center of the VFP _screen. It most of the time is when you run an application in fullscreen mode, but in principle such dialogs and even just messageboxes are not in your VFP _screen. No idea about automatic disconnect on closing of an application.
I guess there is a reason why VMWare and Citrix are used instead of Microsofts own RDP solution. RD also isn't just free, if you need to support many clients. You'll base this on terminal server and that needs CALs.
Bye, Olaf.
Olaf Doschke Software Engineering
It might not work out that well when your VFP application for example uses GETFILE() and a dialog appears, which potentially does not need to be in the center of the VFP _screen. It most of the time is when you run an application in fullscreen mode, but in principle such dialogs and even just messageboxes are not in your VFP _screen. No idea about automatic disconnect on closing of an application.
I guess there is a reason why VMWare and Citrix are used instead of Microsofts own RDP solution. RD also isn't just free, if you need to support many clients. You'll base this on terminal server and that needs CALs.
Bye, Olaf.
Olaf Doschke Software Engineering
- Status
Similar threads
