1 Replies - 2431 Views - Last Post: 30 January 2013 - 07:55 AM Rate Topic: -----

#1 [email protected]   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 29-January 13

vb.net application running slow in server 2008 r2 standard

Posted 29 January 2013 - 11:59 PM

I had developed an application on XP. Later i shifted it to windows server 2008 r2 standard.
The application is running slow on 2008 as compare to XP.
The coding is same. I had tried with sql2008 and vs2010 but there is no improvement on the performance.

So pls. give me solution to improve the performance on 2008 server.

Jignesh Lad
Is This A Good Question/Topic? 0
  • +

Replies To: vb.net application running slow in server 2008 r2 standard

#2 tlhIn`toq   User is offline

  • Xamarin Cert. Dev.
  • member icon

Reputation: 6534
  • View blog
  • Posts: 14,450
  • Joined: 02-June 10

Re: vb.net application running slow in server 2008 r2 standard

Posted 30 January 2013 - 07:55 AM

There could be 10,000 different reasons for this.
There is little we can help you with for this.
NO idea about your code.
No idea if it is the same computer with a different OS, or a different computer.
No idea about the environment or network conditions.
This could be a 32bit/64bit difference.
This could be a lot of different things.

I strongly suggest installing VMware or some other virtualization technology on your development PC so you can create a couple virtual computers for testing. This would allow you to debug and test inside: WinXP32, XP64, Vista, Win7x32, Win7x64... etc. without having to actually have 5 physical PC's. Visual Studio will let you send the debug directly into one of these virtual machines so you can watch it operate, check its variables, see the crashes and so on just as if it were debugging on your real machine.

If you get good performance on the same PC with different OSes, then you know the issue isn't the OS per sae but something else specific to the environment the slow PC is in.

Log files with lots of info that are time stamped. You may need to do a lot more logging for things like start of method, end of method time tracking. If you see a particular method or query that suddenly takes 100 times more time when run against your XP machine, then you know the area of code to work on.

But otherwise... Welcome to software development. Writing code is easy. Writing good code is tougher. Finding all the little idiosyncratic behaviors under lots of OS versions is 90% of the job.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1