On Mon, Nov 9, 2009 at 9:38 PM, Chris <macmichae...@gmail.com> wrote: > > I've recently been in discussion about which is better to have. > > http://media.example.com OR > http://example.com/media/ > > 1) The first method, I've been told, allows you to make more requests. > IE for example can only make like 4 requests at a given time on a > given domain. but, if you use sub-domains, you can make additional > requests (4 additional in the example of IE). > > 2) The second method is a more canonical approach and to me is the > preferred approach. The person arguing this point says that the > additional requests cannot be made on sub-domains b/c browsers issue X > amount of requests on a per domain basis therefore sub-domains do > create additional requests.
Browsers have a limit on simultaneous requests per host name, not per domain name. > > I've also been told that these arguments are really not that big of a > deal. Like nearly everything in computing, there is no absolute answer to this that is correct under all circumstances. But my experience is that downloading more media resources simultaneously will generally improve the user-perceived response time of the initial access to a media-rich page. And, given how important first impressions are, that is very much worth considering. After the first load of a given page, there will be less impact as long as the resources remain cached locally by the browser. > > Which method should I adopt? I personally like the second method, but > if it will effect performance/ loading times at all then I should go > with the first method. I will be serving things like media and API's > on a separate server or instance. Any thoughts? There are a couple additional of reasons to consider option (1). First, since you are serving static resources only, you don't need to serve them with Django -- you can pick a highly optimized web server like nginix or Apache for serving the media resources. Second, they don't have to be served by the same physical server, which can definitely improve your application's scalability. You can play configuration games and accomplish some of both of these benefits with option (2), but it's a *lot* more configuration work. As a final thought, it's instructive to note that the Ruby on Rails equivalent to media-serving template tags have built in support for spreading the media requests, even for a single page, across as many media asset hosts as you wish to configure, with no impact on the templates themselves. And, in a globally accessed application, you can even use asset host names on a content delivery network so that media resources get served from a geographically close server, which will (again) improve the user-perceived responsiveness of your application. Sounds like a few other people in the world have found approach (1) to be worth the effort. Craig PS: WIth regards to aesthetics, does the *user* of your application care what the media URLs look like? Nope, I didn't think so either. So, neither should *you* make that a primary decision criteria :-). > > Thanks in advance for input. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
