generating images in Azure asp.net
I'm currently running a site of a dedicated server but want to scale up using Microsofts Azure cloud platform in the future but im unsure if a certin part of my code will work on azure.
The site consists of a gallery of items with an image for each item. The images are stored in a sqlserver database.
I have created a http handler that caches the images to disk and redirects the request to the image (as shown at th开发者_如何学JAVAe end of the post).
The images are saved into a virtual directory called "imagecache" inside my ASP.NET application. (i.e. ~/imagecache/ ).
As the web app will run in many virtual machine instances on the Azure platform the images will need to be shared between the instances right?
So my question really is.. What is the best way of achieving what I already have on that is compatible wit azure?
Thanks
Image gen code..
public class getimage : IHttpHandler {
private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
public void ProcessRequest (HttpContext context) {
try
{
string uniqueid = "";
if(context.Request.QueryString["id"]) uniqueid = context.Request.QueryString["id"].ToString();
string dir = "~/imagecache/";
string image_target_path = dir + "image-file-" + uniqueid + ".png";
byte[] data = null;
context.Response.ContentType = "image/png";
if (!System.IO.File.Exists(context.Server.MapPath(image_target_path)))
{
if (context.Request.QueryString["id"] != null)
{
// get image data from the database
data = ImageHelper.getDatabaseImageDataByID(Convert.ToInt32(uniqueid));
using (System.Drawing.Image img = System.Drawing.Image.FromStream(new System.IO.MemoryStream(data)))
{
// save image to disk in the virtual dir
img.Save(context.Server.MapPath(image_target_path));
}
}
else
{
// set a sample image if no id is set
image_target_path = "~/images/noimage.png";
}
}
// redirect request to image file
context.Response.Redirect(image_target_path, false);
}
catch (Exception ex)
{
log.Error(ex.Message, ex);
}
}
public bool IsReusable {
get {
return false;
}
}
}
The simple answer here would be to move the image store from SQL to Azure Storage Blobs. The container for those blobs can then be made public and accessed via a URL without the need for you to act as an intermediary with your caching layer.
However, if you still want your applications to act as that intermediary via the http handler, you should still be able to accomplish that with the 1.3 SDK. This verson introduced full IIS which allows you to configure virtual directories and http handlers inside web role.
But I'd really recommend you take a look at the use of publically readable blob containers. It gives you the same level of functionality for a signficantly reduced level of effort. You can even combine the techniques, toss in a pinch of Azure AppFabric cacheing to add more flexibility and features if needed.
As Brent said, Azure Storage blobs are going to help, especially if you enable the Content Delivery Network, which has about 2 dozen nodes worldwide.
Local directory caching won't work with just a local directory, as you'll have a separate cache directory for each instance. This is why many people have been using memcached for their multi-instance caching needs (David Aiken recently posted an article about setting this up in Azure).
Brent hinted at Azure AppFabric Cache, which is currently in a 'preview' mode (you can try it out free, but it's not quite ready for production yet). This will easily allow you to cache data between your instances (even asp.net session state).
How do you choose between Blobs and local cache??? Going with a caching solution such as memcached or AppFabric cache, you'll have more control over who accesses your content, as well as the ability to capture performance counters representing total bytes downloaded. Going with Blobs relieves your role instances of lots of work (networking, IIS processing and byte-converting, coding for cache, etc.) and even speeds up a user's browser experience (browsers typically default to only two concurrent connections to a particular address; blobs would technically be at a different URL). Further, you can use the content delivery network to boost performance on frequently-accessed images.
精彩评论