Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got a client with an MVC v1 (.NET) application running on a micro instance. On this instance, I've got .NET, IIS 7.5, and MS SQL Server 2008 running to handle the application. The client has reported that it is taking nearly 10 seconds to process each request. Even loading the initial login page takes about that long, then logging in takes that long, etc etc.

The currently running instance specs are as follows:

  • 615 MB RAM
  • Intel Xenon CPU E5430 @ 2.66GHz 2.78 GHz
  • 64-Bit

Is the memory availability the issue? or is it the processing power?

I forsee two options:

  1. Change to a larget instance
  2. Set up a 2-tier architecture with two micro instances

Which of these will give the application better performance?

Thanks in advance.

share|improve this question

4 Answers 4

up vote 3 down vote accepted

Running all of that on that instance is definitely going to cause some problems. Whether a 'small' versus '2 micro' instance will work better is a question of cost effectiveness.

To find out what your bottleneck is, you should be able to launch the performance monitor from Control Panel -> Administrative Tools -> Performance Monitor and see what resource is capping out - chances are it's the memory.

If I can remember, the 'small' instances don't become cost effective unless you're looking to exceed three full-time micro instances.

share|improve this answer
    
Yes, from a cost perspective, a small instance is $0.12/hr, whereas a micro is $0.03/hr. I can run 3 micros for less than the cost of 1 small. My concern is whether or not using 2-tier approch will help the performance. –  Honus Wagner Jun 24 '11 at 14:38
    
@rovangju I have the resource monitor open, but I'm not entirely sure what I'm looking for. Some highlights are, (CPU 0% Usage, 100% Max Freq), (Disk relatively low usage. Spikes every now and then to !5-10k KB/sec, hovers around ~5% Highest Active Time) (Network usage seems normal for this site, not much stress, two or three simultaneous users max) (Memory while idle, 0 Hard Faults/sec, 86% Used Phsyical Memory. While active, ~130 Hard Faults/sec, 100% Used Phsyical Memory. sqlserver.exe has 261,148 KB Committed Memory) –  Honus Wagner Jun 24 '11 at 14:50
    
@rovangju Does this basically mean that sql server is hogging up my resources? –  Honus Wagner Jun 24 '11 at 14:51
    
I too recommend looking at perfmon carefully. Hopefully you won't need another VM, but at least that's totally an option. And on AWS, you can EASILY rig it so that the only machine allowed to connect to a given VM is something you specify.. –  Doc Jun 24 '11 at 16:26
    
You'll probably need to add a bunch of pretty specific probes to find the exact metrics that are impacting you. As others have said below - 64bit apps will take up more memory to do the same thing as 32bit versions of the same app.. So, then unless you need high precision math, or the ability to scale up to >4GB of memory, 32bit would be good. –  Doc Jun 24 '11 at 16:30

Optimize your queries to use the disk as little as possible. Databases are governed to a large degree by disk access and what is in cache. By tuning your queries as much as possible, including adding indexes and normalizing the database, you will reduce your resource hit.

People forget that these machines are running in virtualized environments. There is a broker between your VM and access to physical disk. The fewer opportunities this broker has to add a microsecond here and a microsecond there the better off your performance will be. It is entirely possible that your application could be running extremely well on a physical host, but as soon as you move it to this virtualized model you experience performance issues. The efficiencies of the promiscuous use of the host masked any inefficiencies in the application design and query design. Finding these inefficiencies when moving to a virtual model, particularly one where your whole database system is virtualized, happens quite often.

You will experience side financial benefits from your query optimization and database normalization. AWS is a utlity computing environment. You pay for each access to a resource. The fewer times you need to go to disk the more dollars you will save each and every month.

I would also consider physical hosting for your SQL Server instance if the database cannot be modified/normalized or have indexes added. This will fix your cost model for your database instance and improve the performance because now you will have access to one dedicated host for your DB. You will likely have to pay for the bytes in/out between AWS and a physical hosting provider for your DB. You may have other options with vendors that supply both virtual and physical hosting, such as Rackspace, where you wouldn't get hit with the bytes in/out of the provider cloud.

share|improve this answer

I wouldn't expect IO, since micro instance is running only on EBS, which is fast. Instance storage is said to be slower than EBS. But check the performance counters as suggested in another answer.

I would really anticipate RAM, since 615 MB is not much for 64bit system. Moreover if your machine starts to swap, your are going to be charged for additional IO requests for EBS, which makes it even worse in economic sense.

Finally remember micro instance has burstable CPU, and it can achieve 2 ECU in very short bursts, while perform at much lower speed on average. I've seen some benchmarks which were pointing that in longer run micro instance was having about half the speed of standard small. But I expect it strongly depends on how busy neighbors servers it has.

So for the question "Which of these will give the application better performance?" I think there is no definite answer, it will be always application specific - check it. Try both options and then decide. With instances charged hourly such test won't cost you much.

share|improve this answer
2  
Actually I've just read the comment with your values. You need more RAM. If you move your SQL to another machine it should really help. And why don't you use 32bit? It takes less RAM then - every pointer in 64bit take twice as much as in 32bit architecture. –  oker Jun 24 '11 at 15:12
1  
Just one more thing - you can also limit memory allocated by SQL server - msdn.microsoft.com/en-us/library/ms178067.aspx –  oker Jun 24 '11 at 16:05

You don't mention anything about the IO subsystem which may not be helping but from what you say I'd suggest it is a memory problem as 615MB is WAY below the minimum recommended memory requirements for that software stack. You should be able to see this just from the most basic of task-manager stats. Fix that and then look at the IO as they're usually pretty poor on low-end VPS/VM instances too.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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