My application requests an XML file and I need to plan how to host that file so it's always available and zippy
March 3, 2009 5:17 AM   Subscribe

Please give me some input on web hosting planning for a small XML file which might get a lot of requests.

I'm working on an application which allows the user to load an XML file. The XML is less than 2K and will probably be loaded once per usage session, which could happen a few times a day. I can't speculate about how many users there will be, but the outcome that I need to (over)plan for is the one where there are metric fuckloads right out of the gate.

How would you host this file to make sure it is always reachable and zippy? Would you trust one single hosting company to host it? Which one/which plan? Which hosts would you avoid like the plague? Or would you put your eggs in multiple baskets and have a couple of hosts which the app can try in sequence to see if they are reachable? I'm willing to pay for bulletproof uptime and reliability, doesn't have to be a cheapass plan, but it might not be cost-effective to pay for a hosting plan oriented towards customers who need huge amounts of bandwidth or root access rather than the ability to handle lots of simultaneous low-bandwidth requests of one dinky file.

Thanks very much for your input!
posted by Your Time Machine Sucks to Technology (5 answers total)
Best answer: I'd probably go with Amazon CloudFront for this - they distribute your file across multiple servers in different locations for really fast delivery. You pay by the GB, so it's pretty cheap for a small file - probably a lot less than the minimums with other services.

On the other hand, that choice might be a little biased in favor of the new and shiny. A 2 KB file is dinky, even with hundreds of thousands of hits a day, and you could easily host it on a couple of different basic hosting plans for redundancy.
posted by pocams at 6:04 AM on March 3, 2009

I'd recommend NearlyFreeSpeech for this kind of thing - you're unlikely to pay more than a couple pennies a year.
posted by dmd at 6:12 AM on March 3, 2009

Response by poster: Cloudfront looks really great, but I'd be slightly worried about uptime as it becomes more popular. On the other hand, it would be very cheap for my needs and the global caching feature would be extremely awesome. Maybe Cloudfront + 1 robust normal hosting plan as a fallback, and the app can ping Cloudfront and fall back to the regular host if something is up with Cloudfront.
posted by Your Time Machine Sucks at 6:54 AM on March 3, 2009

You might also want to look into RSS topics. On one my of my websites I setup an RSS feed, and it got pounded and I had to remove it. RSS is XML. So, it might be an area where you might find more info.
posted by hungrysquirrels at 6:58 AM on March 3, 2009

Any web host of any merit anywhere should be able to serve a 2k static text file to as many visitors as the server itself can handle (the things that usually bog down web-hosts are scripts and database queries). You don't give any indication as to what you consider to be a "metric fuckload[]", but I sincerely doubt you could tax the capacity of a standard Apache web server with that type of resource.

That said, uptime is probably the main concern and unless you're willing to pay an arm and a leg for some sort of guarantee on your 2k text file, you're probably better off going with Amazon (they guarantee, I think, 99.95%, IIRC) because they're well known and not going anywhere.

Also, I don't know anything about the nature of your app, but please for the love of god consider what might happen to users if, in the future, you stop supporting it and the xml file goes away. Might make the whole app moot, I don't know, but at least come up with a plan. I have a few apps that have died or no longer work properly because their author stopped offering the "check to see it's not pirated" web service so the apps won't run at all.
posted by toomuchpete at 7:49 AM on March 3, 2009

« Older Please Explain Server Spikes   |   Will house prices track stock prices (in NE USA) Newer »
This thread is closed to new comments.