CODEWITHSUNDEEP
c#winformsperformance
Machado
Machado

Reputation: 741

C# Windows Forms application runs slow from mapped network drive

We run a Windows Forms application developed in C# in our company, and one problem is giving us headaches.

When we run the application from a local machine, in drive C:, for example, the application loads and runs fast. It's heavily database-based, which means it does a lot of queries to our MSSQL server, and it runs all queries in less than 1 second, while running from a local drive.

If we run the same application from a mapped network drive (not a UNC path, a M: mapped drive), it loads fast, but the queries takes ages to complete, and hardly we can see the result.

ClickOnce is not an option for us (due to reasons that are not subject to discussion here), and we have several other 3rd party applications that runs fast, loaded from the same mapped M: drive.

I did some research, and the closest question I could find is this one: http://stackoverflow.duapp.com/questions/2554716/my-c-net-application-is-running-slower-when-the-exe-is-located-on-the-network

When I right-click the application there's no "unblock" option available, which tells me that there's no secondary stream attached to the file and it's "trusted" by the machine.

Also, I tried adding <loadFromRemoteSources enabled="true"/> in the .config file, but it caused no changes in the application performance so far.

The application is not signed, and the slowness happens with both debug and release versions of the application.

What are we doing wrong ?

PS: I'm still trying to pinpoint the exact command that's taking longer to work, but no luck so far.

EDIT: Adding new information. It seems that the problem wasn't the network "per se", but the fact that the application was doing a background task and failing because it was running from the network. This failure wasn't wrapped around a try-catch block, and was preventing the background task to return properly, creating a major delay on the application response.

That means it was our development bug, not Windows fault. Thanks for the answers, I'll vote to close this question.

Upvotes: 2

Views: 1883

Answers (1)

miroxlav
miroxlav

Reputation: 12204

I have recently found one scenario where exactly this was happening in application.

On one machine, the application was lightning-fast, on another one, queries took seconds.

Second machine was configured to use VPN dialed via PPTP. The VPN was automatically reconnecting whenever the computer got online – even if the machine was in company network (where no VPN was needed). VPN auto-redial trick always seemed to be very useful... until I found that connection to the SQL server basically always went through the VPN because of this. Manually disconnecting the VPN instantly helped: responses got fast again.

I do not say this is definite solution in your case but this is one of things what causes almost unacceptable slowness of queries. I observed this first hand.

Upvotes: 1

Related Questions