Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am expecting high traffic time to change dns. My existing shared godaddy server may fail. i have less than few hours in hand. i have a another dedicated server ...can i transfer traffic /bandwith /load to dedicated server. what are possible solutions.



share|improve this question

Reduce bandwidth - You may want to use a free CDN such as CoralCDN or SimpleCDN and temporarily redirect visitors to the CDN domain. That's what people normally do for the slashdot effect.

Reduce CPU load - You could also present a static cache of your site made using httrack or similar tool instead of a full dynamic one.

Spread the load - Varnish can cache some content and if correctly configured, can do a lot more, including load balancing over multiple servers.

share|improve this answer

You can change your DNS now and it will have an impact, most definitely. However, if you are storing information server-side (I don't mean session state stuff, I mean taking orders, user input, content whatever...) then this might not be practical.

It takes a full 24 hours for propagation to occur, but if you've got a static-ish site, you can definitely change now and if you are a small to medium site expecting a large traffic spike then the majority of users will be redirected to the new site.

What else you can do depends on your situation. If you are allowing users to login, post to forums, take input etc. then you're going to have a bit of trouble. You can do stuff on the application side, but it's a lot of work, probably not much you can do in a couple of hours. Again, we need more information here to be specific.

However, if you have relatively static content. Like for example, if you were posted up on slashdot then you can have a look at overriding some of the dynamically generated pages with static pages.

  • grab the full HTML of the page from your browser
  • copy and paste it into a file
  • re-upload it back to your webserver
  • use mod_rewrite in a .htaccess file to serve that file for any requests to the original URL

You need to be far more specific with what you're running on the site to give any more specific information. In general, you would be recommended running a caching proxy, but that presumably isn't possible on a shared server.

share|improve this answer
my site is a small CMS.database is in MS access and just displaying content.No Blog,No forum and no cart. – sunny Nov 19 '09 at 11:10
DNS might not take 24 hours... If the TTL on the records are short, changing them will have an immediate effect and a larger one as the records expire from caches. This is why setting TTLs to 3600 or 7200 or so is a good idea, not weeks-long. – Michael Graff Nov 19 '09 at 12:00
ISP's will often ignore short TTLs, but from what I have seen in DNS changes, most will update pretty fast (within the hour). But I would be interested in any stats for for hits over time to the old and new sites after a DNS change for a global high traffic site. – Kyle Brandt Nov 19 '09 at 12:21
@Michael GoDaddy's default TTL is a day, I'm making a reasonable assumption this is what the user is talking about when he says "no time to change DNS" @sunny is anything written to the access database? is it one particular page that you're worried about big loads to or the whole site? Could you dump all of the site out to HTML pages for the time being and remove the access component? – Philip Reynolds Nov 19 '09 at 12:24
Most of the traffic is expected on one page like prospectus download.The prospectus page is dynamic. like one have to put country name then accept terms and able to download. The prospectus is 14mb.I have transferred the downloadble prospectus file to another server for saving bandwidth cosumption. – sunny Nov 20 '09 at 6:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.