Ongoing severe network share performance issues - Server 2008 R2

[pleasehelpme]

Hi,

Am new to the forum and seeking guidance, by trade I am a Microsoft / VMware specialist. Alpha / apps / databases... not my expertise.

I have a client who I upgraded from SBS2003 to a Windows Server 2012 R2 Hyper-V host running virtual Windows Server 2012 R2 Domain Controller with a Windows Server 2008 R2 application server to host Alpha Five. Their business heavy relies on this application. All workstations are running Windows 7 x64.

Alpha Five is accessed via a file share on the application server. I believe Network Optimisation is configured on most of the clients.

Since the system has been upgraded, the performance has been dreadful, we have not had much luck with out Alpha programmer to troubleshoot the issues and it's been going on for way over a year now, to the point it is disrupting my clients business and causing me a dreadful headache.

The strange thing is, I just had 10 days of the application running the fastest it has ever been, then it fell over again. All network switches and cabling has been replaced. If I copy a file from the network share to the client I got approx. 30/40mbs. All other applications on the servers run flawlessly.

Last night I disabled SMB2 and oplocks on the server, I am currently in the process of disabling oplocks on the clients and getting them to test, my initial tests last night still were not impressive compared to running the database directly from the server.

There could be as many as 7 users accessing at any one time. Any help or guidance would really, really, really be appreciated..

Many thanks - Chris

[Tom Cone Jr]

Re: Ongoing severe network share performance issues - Server 2008 R2

Chris,

If performance was acceptable before the upgrade to the new Server software, maybe this will help ...

The typical setup would install the Alpha Five program files (usually the runtime engine) on each work station. Users crank up A5 locally and connect with the database on the server. The connection can be direct or through a "shadow" copy of the database on the local workstation. "Shadow" copies are created by the network optimization sequence you mention. The database files themselves are stored only on the server. In many cases directly opening the database on the server will be functional, but a bit slow. Usually not dreadful. Opening the database through the local "shadow" copy is usually faster and therefore its usually recommended. There is some debate whether mapping the database folder (on the server) as a local drive is necessary or helpful these days. I usually do it. However I'm careful to use the same drive letter designation on all the workstations.

Is it possible real time anti-virus software is running on the server (or workstations) to monitor disk activity? If so you should probably disable or exclude the database folder from the AV monitoring.

I don't have specific experience with the server setup you describe, so watch for other posts from more experienced folks, here.

Good luck.

-- tom

[pleasehelpme]

Re: Ongoing severe network share performance issues - Server 2008 R2

Thanks for your reply Tom.

Sorry I did forget to mention that all users access the database from the same mapped network drive. I believe some of the coding points to the mapped drive instead of a server/ip name too.

I have excluded all database locations and mapped drives on the server and clients from RTVS. Any location Alpha resides is excluded. That was my first port of call. Should have said this in my first post.

Need to double check each client for shadow copies, is it a simple case of Tools, Network Optimisation, Create Shadow, Choose Location - Then in future open the file it creates ?

Thanks again

[Tom Cone Jr]

Re: Ongoing severe network share performance issues - Server 2008 R2

....is it a simple case of Tools, Network Optimisation, Create Shadow, Choose Location - Then in future open the file it creates ?

Yes. Start Alpha Five on the workstation. Use File / Open Database to open the database on the server. Close any startup forms to reach the Alpha Control panel. Then Tools / Network Optimize. At the end of this sequence Alpha will open the database through the new shadow copy. This happens automatically. Close the opening form to get to the Alpha Control Panel. Then Tools / Create Shortcut to put a shortcut on the user's desktop. Thereafter the shortcut will start alpha and open the shadow automatically.

[Tom Cone Jr]

Re: Ongoing severe network share performance issues - Server 2008 R2

Chris, an easy way to begin troubleshooting your performance issue is to put a copy of the database files in a shared folder on one of the other workstations. Then open the database there from a different workstation. i.e. start alpha five on the other workstation and from the Alpha control panel use File / Open Database to open the database from its new (temporary) location. Don't bother to network optimize. Test performance when no other applications are being run on the "temporary" server. I would expect snappy / brisk speeds, but not blazing. You would not want to use this for live data entry of course, but it will be adequate to determine if the slow down you're seeing is related to the configuration of the "real" server. Is performance comparable to what you're seeing with the "real" server?

[user10]

Re: Ongoing severe network share performance issues - Server 2008 R2

Networking an alpha app is very basic stuff so I wouldn't start looking there!
It looks to me like its more a server configuration issue!
How many clients are on the network?

[pleasehelpme]

Re: Ongoing severe network share performance issues - Server 2008 R2

Thanks Tom, will give it a try to rule it out. This is only app we are having performance issues with.

There are only about 10 client computers on the network, it is a very small, simple setup. 1GB network throughout. As far as it being a server configuration issue, what could it be? It is only sharing a folder with the database in it.... am I correct?

[pleasehelpme]

Re: Ongoing severe network share performance issues - Server 2008 R2

Would upgrading to V11 help at all?

[Tom Cone Jr]

Re: Ongoing severe network share performance issues - Server 2008 R2

Chris,

Using v10 on a Win 7 Pro box, several have recommended installing the runtime engine for each workstation OUTSIDE the program files or program files (x86) folders. This is how I do it as well.

Let us know what you discover when running the app against the "temporary" server.

I have no experience with Hyper_V sessions, so I don't know if moving to a more recent version of Alpha Five would help.

[pleasehelpme]

Re: Ongoing severe network share performance issues - Server 2008 R2

Thanks Tom, do you think I should back out my change with disabling SMB2 and OpLocks, I don't think this has made any difference in performance.

I will test and let you know the outcome on;
1. Running from a "temp" server
2. Moving the runtime install location (why do we move this?)
3. Re-configuring shadow copies (only setup on a couple of machines)

It shouldn't matter that it is a Hyper-V / VMware / Physical server if all it is seeing is a file share, theoretically.

[DaveM]

Re: Ongoing severe network share performance issues - Server 2008 R2

http://forum.applicationallstars.com....php?f=19&t=73 on shadowing, if it helps.

All my station folders are setup like:
alda with runtime installed
folder with shadow inside

I don't use mapped drives like Tom does, but not due to speed reasons.

[Ray in Capetown]

Re: Ongoing severe network share performance issues - Server 2008 R2

The distinct advantages of using a mapped drive letter is mobility.
Mainly, you can replace or move a server without changing any startup, simply map the server folder to the same drive letter.
Secondly use standard launch icons on any installation.

[DaveM]

Re: Ongoing severe network share performance issues - Server 2008 R2

The disadvantage to drive letters is that people tend to start looking at what is in there and then star messing with it. My only real reason for not using them.

[Al Buchholz]

Re: Ongoing severe network share performance issues - Server 2008 R2

The strange thing is, I just had 10 days of the application running the fastest it has ever been, then it fell over again.

It's always tough to find these conflicts.

I've found anto-virus, on-line backups, firewalls, and other things that have caused delays.

Usually temporarily turning off each system will help isolate the problem.

A bad network card on a machine that is turned off while someone is on vacation can do it too..

Triage is so much fun. NOT. But challenging.

I've not been a fan of mapped drives since MicroSoft started pushing UNC - \\servername\sharename.

[Ray in Capetown]

Re: Ongoing severe network share performance issues - Server 2008 R2

A bad network card on a machine that is turned off while someone is on vacation can do it too..

I have had a couple of those - in both cases though there was occasional data corruption.
In one case reportedly the computer was be off at the time - I might additionally suggest in the TRIAGE process to disconnect cables individually.