Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a number of Windows Server virtual machines that we use for .NET and Java development and QA. I find Azure attractive for the obvious reasons but mainly for the opportunity to reduce non-productive hours spent on environmental maintenance.

Functionally, after cleaning up system id issues with some of the apps (licensing, et al.) all is fine, but the performance is somewhat lacking:
Our system takes about 2 minutes to build its solution when running on either Hyper-V or ESXi, but the Azure A3 machine is taking up to 12 minutes to perform the same build.
The resource Monitor shows that most of the time the machine is in IO wait reading the disk.

Is there something I should be doing differently or should I expect better performance from local machines in all cases?

share|improve this question

Azure VMs are sized based on their RAM and CPU cores, but all sizes are conspicuously lacking in storage performance, which always becomes the main culprit regardless of how many cores and memory you throw at a VM.

Two solutions:

  • For normal usage, just attach as many data disks as possible to your VM and configure them in RAID 0 in the guest system; I/O is capped at the disk level, thus more disks = more I/O. Use those disks for actual work, don't put anything other than the O.S. on the system disk (which is a best practice anyway). This strategy has no additional costs, because Azure storage is billed based on the actual space used: the number of virtual disks and their apparent size don't matter at all. (*)
  • If you really need disk performance, use premium storage.

(*) If you are concerned about using RAID 0, don't be so. Those are virtual disks, and their integrity is already guaranteed by the underlying storage layer. RAID 0 is only used to group them in a single logical volume with better performance.

share|improve this answer

Azure is a shared service. You should expect random performance variations based on the load on the hypervisor you're running on (which you have absolutely no control over), and a literally infinite array of other factors (which you also have no control over).

If performance (and consistency) is critical host your own environment, on your own hardware.

share|improve this answer
1  
While this is technically correct, there are guaranteed resources for each VM tier, so it doesn't apply if you size your VMs carefully. Unfortunately, storage I/O performance in Azure VMs is really awful even at the highest tiers. – Massimo Jul 24 '15 at 10:41
1  
-1 because it does not address the question. For the correct answer - Massimo nailed it: Azure is pathetically slow generally, but there is a high IO storage tier that can be used. – TomTom Jul 24 '15 at 10:51

You shouldn't use your c drive for applications:

http://blogs.msdn.com/b/igorpag/archive/2014/10/23/azure-storage-secrets-and-linux-i-o-optimizations.aspx

The C drive is optimized for boot time, not for high IO.

As each disk is IOPS-throttled (normally 500/disk), you can either use many of them (up to 8 on A3) or us a machine from the d-series with SSD (D3: 12000IOPS). Note that you have to use the d-drive which doesn't guarantee to persist data to have SSD speed:

http://azure.microsoft.com/blog/2014/10/06/d-series-performance-expectations

Or you can pay $$$ and use a premium storage blob (~100$/Month for 5000 IOPS) to have a persistent storage.

share|improve this answer
2  
NEVER use the D: drive to store anything even remotely important. That's temporary storage, and it can/will be emptied at each VM reboot. – Massimo Jul 24 '15 at 10:39
    
@Massimo Well, did you read the OP? He talks about a build server. It would occur to me that builds are a perfect issue for temporary storage ;) – TomTom Jul 24 '15 at 10:52
    
As long as you know it's temporary storage and only use it as such, it's of course fine. But this is not addressed in the answer, and someone could easily make huge mistakes because of this. – Massimo Jul 24 '15 at 10:54
    
I've edited the answer to avoid any such mistakes - better one warning too much, right? – Jack Jackson Aug 26 '15 at 15:08

We moved our entire production environment to Azure about 6 months ago. We have a build server that runs several builds daily and based on the duration of individual build tasks from build to build I can tell you that "performance" is fairly consistent. I can also confirm your findings that processes that don't utilize multiple cores (e.g. running unit tests) run about 6x slower on an Azure VM compared to a local development PC.

In short, when you're running processes on a single core your local machine will always outperform an Azure VM. I think Azure is better suited for handling tasks that involve multiple cores (e.g. a database or web server), because you can easily scale up/down cores as needed.

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.