Portal Home > Knowledgebase > Articles Database > Image hosting - Same server or different server?
Image hosting - Same server or different server?
Posted by AjiNIMC, 05-17-2007, 01:45 PM |
Hi,
Purpose: I want to make my site load faster
Different Options
Host images under the same domain - So no additional three way TCP handshake required. Different subdomain for images - Browser pipelining can be utilized. Different domain altogether - Browser pipelining can be utilize and also can avoid the site wide cookies with every request.
What is your opinion about this?
Thanks,
AjiNIMC
|
Posted by f0mp, 05-17-2007, 05:59 PM |
This is true only if you're using the same server and http/1.1 pipelining.
Necessary if you're on a second box. Has nothing to do with pipelining on its own though.
That sounds like a very weird idea.
Basically you can forget about the third option. Decide between the other two as follows:
Are the images on a separate machine, or do you plan to move in that general direction in the foreseeable future? -> subdomain
Same box, no plans -> same domain.
|
Posted by ub3r, 05-17-2007, 06:44 PM |
Mine is setup like this:
www.photos.cx & photos.cx
Main home page, file uploads are handled. Local uploads are sent to /home/img/www/.
a.photos.cx
nginx installation that chdirs to /home/img/www/ and serves requests for images, and only images. No php, perl, or any server-side execution is enabled.
b.photos.cx
Hosted on a super-high-quota shared hosting account I have. This subdomain only serves requests for the uploader which sends data to /home/photos/www/c/
c.photos.cx
subdomain on that same shared hosting account as b.photos.cx. Serves images from /home/photos/www/c/. Php, perl and all server-side-programming stuff turned off.
As the service grows, i'm just going to add more of the same. d.photos.cx will handle uploads, e.photos.cx will handle images with php and perl shut off. Depending on prices, I'll either run apache to serve images (for shared hosting accounts), if I run it on a vps or a dedicated server, i'll serve images with nginx. The service doesn't use any cookies, but all file upload data is stuffed into a database that resides on the main photos.cx server. The database includes upload id, filename, ip of uploader, host of the upload, and the user's declaration of whether or not they want their image on the random image / rss feed.
|
Posted by AjiNIMC, 05-17-2007, 09:32 PM |
http://blogs.msdn.com/ie/archive/2005/04/11/407189.aspx this can help. We can do browser settings to improve it.
1) http://www.debtconsolidationcare.com...rer-tweak.html - This is for internet explorer
2) http://www.debtconsolidationcare.com/firefox-tweak.html - This is for FF.
With subdomain now we have 2 domains so 4 connections (default). https://addons.mozilla.org/en-US/firefox/addon/3371 can help us understand the overall loading.
Look at Yahoo, there images are hosted at yimg. IMO third option is the best when you have .domain cookies.
It works better but if you have domain wide cookies with .domain then it is good to have a different domain as with every request the cookie data also needs to be packaged and sent.
|
Posted by f0mp, 05-18-2007, 03:53 AM |
Unless you have multiple cookies, each very long, that sounds like the wrong place to be trying to save bandwidth. Most websites have a single cookie with only a session id in it.
|
Posted by AjiNIMC, 05-18-2007, 04:42 AM |
Not just to save bandwidth but to improve the user experience (the speed), even the smaller change can help improve the user experience to a higher extend.
I have seen yahoo and some other bigger websites practicing this. But since Amazon have a very simple cookie they go for method 2.
I think the most optimized way of handling images/css/js is having another domain. Can you point any negative point (apart from manageability, we can do it easily with a softlink and robots.txt) with method 3?
Thanks for the reply.
Aji
|
Posted by AjiNIMC, 05-18-2007, 04:49 AM |
OOps, my mistake even amazon is using a different website for image hosting images-amazon.com.
|
Add to Favourites Print this Article
Also Read