Earlier this year, I implemented an interesting architecture for serving images. The company had a web site with a searchable portal for real estate listings – about 1 million of them with over 20 million images associated with the listings – which was growing as sluggish real estate sales caused listing inventories to grow nationwide. In addition, a new version of the portal displayed additional images in the search results. This situation caused the company’s primary image disk storage array to be extremely stressed, especially while loading new images. The secondary site was off line due to upgraded disk appliance o/s software that was too memory intensive for the model of disk appliance in service. To resolve that required rolling back the software to an earlier version; then reloading the image files on that appliance by transferring the images from the primary site disk array, further stressing the primary hardware. The job was going to take about 10 days, and performance was suffering.
The idea that solved the problems was to cache images on servers at a third party location. Since the company had already signed a contract with a third party to host and serve video, trying the image cache approach for the company made sense. Within 5 business days, the company had implemented the changes needed and had started to cache images on servers at a third party location. Most of that time was spent waiting for the vendor to set up the systems on their end. The changes on the portal servers were relatively simple and implemented within a day or two.
The cache was pretty easy to implement. Code is changed to request the image from the third party URL instead of the traditional source. In this company’s situation, this was easy because most images are called with a data base function that builds a URL for the call and executes the request for the image. So, all the IT staff needed to do as revise and deploy that function.
Once the request is directed to the off site cache, the image is served if it is cached. If not, the 404 error invokes software on the cache that gets the image from the source. In this company’s situation, that source was multiple sources in an image structure behind a F5 load balancer. The cache vendor then serves the image and copies it to their server with concurrent processes.
Images stay on the vendor’s servers for a time set by the customer. The portal company used a 2 week time to live (TTL). This means if an image is not used for 2 weeks; it is automatically removed from the vendor’s cache. The vendor distributed the company’s images on 1000 servers, so the company had to add 1000 names to its DNS records.
The cost of this service is very reasonable compared to the cost of adding or upgrading disk appliances to meet the growth in images stored. For a few hundred dollars a month in vendor services, the company avoided disk appliance upgrade that may have cost as much as a half million dollars.
For more information about this project, or to discuss other issues related to large scale image storage for web delivery, contact me at 757.675.5010 or email bobpride @ cox.net. (Remove the spaces before and after the @ --- I have to put them there to fool the spammers’ bots.)
The idea that solved the problems was to cache images on servers at a third party location. Since the company had already signed a contract with a third party to host and serve video, trying the image cache approach for the company made sense. Within 5 business days, the company had implemented the changes needed and had started to cache images on servers at a third party location. Most of that time was spent waiting for the vendor to set up the systems on their end. The changes on the portal servers were relatively simple and implemented within a day or two.
The cache was pretty easy to implement. Code is changed to request the image from the third party URL instead of the traditional source. In this company’s situation, this was easy because most images are called with a data base function that builds a URL for the call and executes the request for the image. So, all the IT staff needed to do as revise and deploy that function.
Once the request is directed to the off site cache, the image is served if it is cached. If not, the 404 error invokes software on the cache that gets the image from the source. In this company’s situation, that source was multiple sources in an image structure behind a F5 load balancer. The cache vendor then serves the image and copies it to their server with concurrent processes.
Images stay on the vendor’s servers for a time set by the customer. The portal company used a 2 week time to live (TTL). This means if an image is not used for 2 weeks; it is automatically removed from the vendor’s cache. The vendor distributed the company’s images on 1000 servers, so the company had to add 1000 names to its DNS records.
The cost of this service is very reasonable compared to the cost of adding or upgrading disk appliances to meet the growth in images stored. For a few hundred dollars a month in vendor services, the company avoided disk appliance upgrade that may have cost as much as a half million dollars.
For more information about this project, or to discuss other issues related to large scale image storage for web delivery, contact me at 757.675.5010 or email bobpride @ cox.net. (Remove the spaces before and after the @ --- I have to put them there to fool the spammers’ bots.)
.jpg)