Cloud Cover Episode 21 - Your Questions Answered
- Posted: Aug 06, 2010 at 1:04 PM
- 34,016 Views
- 7 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- WMV (WMV Video)
- MP3 (Audio only)
- MP4 (iPod, Zune HD)
- Mid Quality WMV (Lo-band, Mobile)
Join Ryan and Steve each week as they cover the Microsoft cloud. You can follow and interact with the show at
@cloudcovershow
In this episode:
In this episode:
- Listen as via forums and Twitter we field questions regarding the Windows Azure topics you want to know more about.
- Discover a tip on effectively using Table naming to more easily manage querying and deleting Tables.
Show Links:
Loading Data to SQL Azure the Fast Way
FTP to Windows Azure Blob Storage Bridge
How Fast Can a Cloud Run?
SL4 XNA Platform Level Editor for WP7
Programmatically Changing the Firewall Settings (SQL Azure)
Secure Use of Cloud Storage Whitepaper
Adaptive Streaming with Windows Azure Blobs and CDN
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
Thanks for the show! Always fun and interesting! Though you could cut back on the who's who jokes
I have to say I really like the idea of letting the community ask questions. I would love if this could be a fixed part of your show like tip-of-the-week
In the spirit of one-question-only 
:
1a) Recently I tried to deploy a simple worker role that basically did nothing but wait. Still it took over several minutes from "Initializing" to the "Ready" state was shown. This caused me to believe that my package was buggy. I actually used several hours to finally figure out that I just had to wait for like 5 minutes. Can you explain why starting an app takes so long?
1b) Will there be some more diagnostics available for apps that don't even start? I know about IntelliTrace, but let's face it, not every company out there can afford the ultimate edition of VS2010... Many times I've uploaded packages that won't run for some reason (forgot to change devstore, used a non-native dll ref without local copy and what have you). This is by far the biggest pain of the windows azure experience right now.
1c) On a related note to the question above, why does deploying a package first have a screen with a button saying "Processing..." and then afterwards shows a progress bar saying "deploying...". And when you click "Run" it says "Enabling deployment...". What are all these seemingly identical processes doing?
1d) Still related to the above somehow, ehem... As mentioned, you thought about doing a piece on the service bus. Well, what about a piece about how to set up access from azure to your on-premise sql server? This is what every man, woman and androgynous person wants and dreams of.. Well, at least until sql azure gets backup capabilities
Why is the managed storage API for queues so slow compared to the REST API? According to my tests the REST API seems to be substantially faster.
I thought it was just a wrapper for the REST API...
Here are some performance numbers for adding 100 "hello azure" messages into a queue (using ThreadPool for each message insert) from on-premise:
Managed API: 15,287 ms
REST API: 7,758 ms
Can this have something to do with internal locking in the managed API upon calling AddMessage() or something like that?
I also made my own tcp/ip server running inside azure in a worker role for adding messages to the queue. And by my homegrown tcp/ip worker role I got just over 3 000 ms in adding 100 messages from outside azure (under half the time the REST API uses). What about making a general tcp/ip interface towards the queue API and making a managed wrapper over that on the client side?
But the really strange part is that the managed api was even slower inside an azure worker role than from on-premise. How can that be??
From within a worker role in azure, adding 100 messages took over 20 000 ms (5 000 ms more than from the outside)..
Thank you for the answers!
It's actually much clearer now that you tied in the fact that config settings are runtime-editable, the management is way smarter with different subscribtions & the usage of staging for swapping purposes mostly.
Cheers!
LOL.. That bear image is out of one of my presentations on Azure. Great work!
1a) Recently I tried to deploy a simple worker role that basically did nothing but wait. Still it took over several minutes from "Initializing" to the "Ready" state was shown. This caused me to believe that my package was buggy. I actually used several hours to finally figure out that I just had to wait for like 5 minutes. Can you explain why starting an app takes so long?
The normal deployment time is anywhere from 5 to 20 mins. I regularly see around 10 or so. It depends on many factors, including how many upgrade domains you have, the number and size of VM you have requested as well as other factors. We are trying to get that time down to minutes, but keep in mind it is a more complicated process than 'boot VM'. There is a bunch of work we do to start monitoring, configure your network, configure the ip filters, etc.
1b) Will there be some more diagnostics available for apps that don't even start? I know about IntelliTrace, but let's face it, not every company out there can afford the ultimate edition of VS2010... Many times I've uploaded packages that won't run for some reason (forgot to change devstore, used a non-native dll ref without local copy and what have you). This is by far the biggest pain of the windows azure experience right now.
Yes, in the next version of Diagnostics, we intend to pull that code outside of your role's running code. This means it will survive crashes and recycles. The problem today is that if your role crashes before the monitor can start, there is no way to monitor. Once the monitor starts outside of your role instance, the issue goes away.
1c) On a related note to the question above, why does deploying a package first have a screen with a button saying "Processing..." and then afterwards shows a progress bar saying "deploying...". And when you click "Run" it says "Enabling deployment...". What are all these seemingly identical processes doing?
Actually, good question. I will have to check to see exactly what the UI matches to, but in general those events are related to the status as reported by the fabric controller for your roles. So, deploying the VHD, booting the VM, configuring the network, launching the role process, hooking to load balancer, establishing heartbeat... etc.
1d) Still related to the above somehow, ehem... As mentioned, you thought about doing a piece on the service bus. Well, what about a piece about how to set up access from azure to your on-premise sql server? This is what every man, woman and androgynous person wants and dreams of.. Well, at least until sql azure gets backup capabilities
We will have an episode on the SB and briefly touch on that scenario, but it is an interesting idea to dig into more deeply. Keep in mind that Project Sydney (which we showed at PDC last year) is designed to bridge networks between cloud and on-premises and can also be used to connect SQL Server on-prem to the cloud (that was the demo at PDC actually).
Regarding your last question on the REST versus Managed API - it is hard for me to diagnose what is happening without seeing the code. There is zero difference between using the .NET API in the StorageClient library versus using REST directly. At the end of the day, it is a series of HTTP methods (PUT, GET, HEAD). If you are seeing a difference, it must be some other factor other than the API itself that is causing it. If you have a small repro, I would actually post it to the Windows Azure forum, where the product group monitors and can quickly respond.
Thanks!
Thanks a lot for your answer, Ryan. I've been looking forward to it. You and "Bed Intruder Song" is what keeps the internet so amazing!
And windows azure, of course! I actually feel very privileged to have you answer my questions.
Remove this comment
Remove this thread
close