-1

Our current Information System (complete with path for pictures for records stored in db) has the following specifications:

  • A desktop application was developed in vb.net
  • We use SQL server 2008 r2 as the database
  • Server specs: Intel xeon processor clocking in at 2.40 ghz, 2 GB RAM and Operating system
    of 2008 R2
  • Hamachi VPN for our offshore offices (within country).
  • Office has 6mb dedicated internet connection. Offshore offices have varied ranging from 2mbps to 1mbps

The application made in vb.net is connected to the server via IPaddress(locally) and hamachi public IP (for offshore)(we made sure that the tunnel is direct, not relayed)

We found some weird things while users used the application. There are times where there are 5 users (local and offshore) simultaneously using it, and it went great. Then there would be times where even just three active users (still local or offshore) would suddenly experience extreme slowdown (even for something as simple as a select query to database for verification of log-In).

For offshore clients we tried to ping them in hamachi and found out that each has speed averaging at 500 bytes per reply. Also, loading records that have pictures in them takes a REALLY long time. Wasn't it supposed to be that if you put image path instead of using BLOB, imaging would be faster? (The applications images is stored in a shared folder on the server, then we map that folder to the client unit).

The questions are: based on the given above, how can we exactly speed up the system? Should we improve the server specs? is the internet provider the problem? must we redesign how we manage pictures in the system?

What are the bottlenecks and how do we remedy it?

Are there any other things that I should be aware of?

closed as too broad by gbjbaanb, Dan Pichelman, ozz, Michael Kohne, GlenH7 Oct 1 '13 at 12:21

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

0

I can give you only one general advice: when trying to make relational DB access over VPN, check your latency. Even when your band width is great, the latency caused by VPN internals might kill the performance in such a scenario. To my experience is often better to make use of a terminal server solution and run the application only locally - RDP is greatly optimized for VPN access, while relational DB access typically does lots of roundtrips with small sets of data, which does not work well when your latency is high.

If that does not work, the best thing to do is IMHO: measure, measure, measure! The bottleneck can be everywhere and it is almost impossible to solve it at the drawing table.

  • Hello Doc Brown. I measure latency via pinging the IPs provided by hamachi on our server. Funny thing is, it's highly inconsistent. One moment it is 45-90ms, the next it's 350-500ms. Would the obvious solution be that we increase all internet bandwidths on all sites? – Malky.Kid Oct 2 '13 at 6:02
  • @Malky.Kid: you missed the point - increasing bandwidth does not help when latency is the problem. Relational DB access often does dozens of roundtrips with small amount of data for a single query - if each roundtrip needs 0.5 seconds (even if you could send theoretically 1GB per request), the performance will drop. The obvious solution is trying to use a terminal server, where the application runs locally without VPN, as I already wrote above. – Doc Brown Oct 2 '13 at 6:42
  • Unfortunately Doc, we really need to make it so that offshore offices are connected to our network. Is VPN the only way to go or are there other solutions I can take on? Is there some way to connect a terminal server to offshore areas? – Malky.Kid Oct 2 '13 at 7:29
  • @Malky.Kid: it seems you still have troubles to understand me - my suggestion was to use your VPN connection to run a terminal server client in your offshore office, not to disconnect them from your network. The DB application then runs locally on the terminal server, and the TS client maps the local session (screen, keyboard) to your offshore office. Things like printing from the application will work a little bit different, then, but you are not the first who has solved that problem, just google for "Terminal Server" or "Remote Desktop" to learn more about it. – Doc Brown Oct 2 '13 at 8:06
  • "The DB application then runs locally on the terminal server, and the TS client maps the local session (screen, keyboard) to your offshore office." Thanks for that idea. Teamviewer Perhaps? – Malky.Kid Oct 2 '13 at 11:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.