when to use "image bank"?

[searain]

We saw these in some huge sites. such as www.msn.com. But the images they used on www.msn.com may be saved in and get from an image bank site, for example, images.msn.com.

I think this "image bank" approach is for the huge sites, they have mirror sites and all these mirror sites could share the "image bank" site, images.msn.com, instead of every mirror sites have its own package of images.

My graphic designer want to use this kind approach in our small to middle size e-commerce projects. such as www.mysite.com and then use images.mysite.com to hold the images for www.mysite.com.

I don't see the points using the image bank in the small to middle size e-commerce sites.

Why use two web sites (1 major site, and 1 image bank of that site) for one web site job?

Unnecessary DNS traffic. Now the page in www.mysite.com when have the images from images.mysite.com has to do the dns search first.

Many times in the php programming, i can use server_root this kind environment variables, now if it break to two different sites, i cannot use these built in variables sometimes.

The list not to use image bank approach can go on and on. But I need some third party expert voice to convice my designer.

So my questions are in what cases and why to use the image bank approach? (why msn use this kind approach etc.)

So I can convice my designer that msn use it for good reasons, but these reasons are not there for our projects.

Any help? Thanks!

[AstroTeg]

I'm just taking a guess here since I haven't had an opportunity to deal with this specific scenerio. I was at a shop that had a collection of web sites that pointed everyone to one completely different URL for file downloads. The reason for this is really network related. By having images.[domain].com, you could point this to any server you wish. You could point it to a server farm. You could point it to a collection of fast acting caching servers. By doing this, you reduce the network load on the actual web server by taking high demand, high bandwidth content off of it. Plus, you could, in theory, have multiple DNS entries for images.[domain].com that point to other servers in other geographical places so if one image server goes down, another one will be there to pick up the slack. I could be wrong, but I would think it would be easier to manage load balancing servers if you task them off with serving images and serving content. What's also nice is if you have images.[domain].com pointing to a different server, you, in theory, should be able to upgrade and do whatever you like to that server without effecting the hosting environment your web apps live in (say, if you decide to change the OS or even to some sort of file storage appliance).

I think this is really more of a networking question. If there's networking guys that are there to implement this, then great. But if its just you, then this could be considered overkill, especially if its all taking place on the same server (unless of course future plans dictate a growth rate which requires planning like this).

[bpat1434]

Well, I'm not an expert, but have used this type of setup before.

I can say that it is a good idea for large sites. Mainly, if your site plans on using lots of images, or you plan on having the same page displayed on different servers, an "image bank" is a good idea. Here's my situation and how it ended up:

I was designing a new website and wanted to ease the structure so I created an image bank called images.site.com. That was great. If I wanted logos it was images.site.com/logos/*.jpg. The nice part was when I created different pages in different level directories that used the same code and images as other scripts, I didn't have to change a thing. It was all centralized. It also helped when it came to downloads for photos or images to use on shirts and other paraphenalia.

The downfalls came when the sub-domain wasn't registering during DNS updates. Although the downtimes were minimal, it was an inconvenience. So I switched to the old way of doing it using relative paths: "../images/logos/*.jpg".

One thing that I can say is this: It really doesn't matter. Appease your customer and do it the way they want, but just warn/inform them that it may not be the best for their needs. If they have plans that the site(s) will grow, then leave them be. And just because you create an image bank, it doesn't mean you can't refer to it relatively.

http://images.mysite.com
http://www.mysite.com/images

They're the same. So would this index.php that is located here:
http://www.mysite.com/articles/2005/July/article1.php
../../../images/.jpg
http://images.mysite.com/.jpg

It's truly up to you and your customer as to which one you do. I haven't noticed any slow-downs due to having to look up the DNS. Just my 2 cents.

~Brett