This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(236.8, 8%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMV%3C/text%3E%3C/svg%3E)
I have an ASP.NET Web Forms app deployed to an Azure app service that utilizes an Azure SQL database. I upgraded from an S1 app service plan to S2 and seemed to get slightly faster page request times, but most pages are still painfully slow.
My website is [www.tenpindoctors.com], and the page most obviously slow is the "Store" page, at [www.tenpindoctors.com/Store.aspx]. That page uses an SQL query to display store merchandise on load. Sometimes it takes as long as three minutes to load. Testing the same query on my SQL Server connection, it usually takes no more than 20 seconds to load as opposed to. The average HTTP request is probably 75 seconds, so given the same amount of time for the query, the back-end coding would usually amount to 55 seconds of latency. For my database, I upgraded from an S1 pricing tier to S3, which went from 20 to 100 DTUs, along with 250 GB of maximum data size under geo-redundant backup storage. I feel like the database queries can be optimized a little, given the fact that the Store page only loads 17 records for store items. There are image BLOBs stored, and when I neglect that varbinary column for storing images, the query loads immediately. What are my options for improving my Azure SQL database plan without upping the price too much? Also, would standard database practices like using indexes and/or stored procedures make much difference for the performance of a query that fetched image BLOBs?
As for the performance of the HTTP requests, 55 seconds of delay is definitely a problem. The technique I use is an AJAX call to an ASP.NET Web method, which includes a return of an image's data URI in the JSON of the AJAX response. I'm not sure if the lengthy data URIs are causing significant delays, since I had to increase the maximum length of the returned JSON string. I'm open to ideas on how to return the image data for better performance.
I'm also not sure if upgrading my app service plan from a Standard plan to Premium would improve performance much. Even if it did, the price would increase by a substantial $300 per month. In this question, I used the Store page of the website as an example. However, it is certainly not the only page with lengthy delays. The only pages with lengthy delays are dynamic and data-driven. From what I've seen, though, the hindrances are mostly a result of the means of fetching the data into views, not just the queries themselves. Feel free to browse the site; I'm open to any recommendations.
Hi,
From your description, I would recommend moving the image BLOBs to files instead, and storing links. That way the query will return fast as you say, and the image files can be retrieved by the client rapidly as well. You may even consider edge caching for the image files so they are even faster.
-TP
Okay, I browsed your site a bit. Let me expand some on my answer.
You would potentially add two columns to your table that stores the products, image_small and image_large. In image_small column you would have the file name for reduced size version of each file you have now, and in the image_large column you would have file name of full-size image (same image as what you have now).
On app service site, you could have separate folders for small images and large images. You would copy the relevant files into these folders.
In your app, you modify it so that upon the initial store home page it is loading the small images by sending URI of each small image file, and then if someone clicks on one of them the larger image is fetched and shown. Using reduced-size images for the initial load of the store page will decrease load time, especially for people with lower-speed mobile connections.
Since you are sending the paths to each image the client browser will retrieve the image files from your site. To be clear, the file name only is being retrieved from the database, and the rest of the URI is from your code and will be the same for all smalls and all larges.
Once you have made all of the above changes you shouldn't need that powerful of App Service Plan or Azure Sql Database SKU to provide decent performance.
Please let me know if the above makes sense to you or if I need to clarify.
@Max Voisard Did you see my replies above?
TP,
I did just what you said with using image URLs instead of BLOBs, and it is nearly 100% faster...it now takes less than a second to load.
I have heard from the man I've made the site for that he's received reports of various pages with slow response times, like for the one I gave an example of, yet I'm starting to think it has little to do with the pricing plans and more to do with poor coding techniques. I'll keep that in mind as I try to boost the site's performance.
@Max Voisard That's great! Please click Accept Answer to close up this thread.
One other page I remember is when I clicked on Forums there was a delay before the page loaded. I only tried loading that page once, so it could've just been a compile delay or similar.