3 ms·
At this point do they really have a option besides continue until Github caves because of mounting costs? Admitting whoops, unauthorized sneaky hackers co-opte
by jauer 12y ago
At this point do they really have a option besides continue until Github caves because of mounting costs?
Admitting whoops, unauthorized sneaky hackers co-opted our national packet mangling infrastructure would be a LOT of egg on their face.
- jfoutz 12y agoThat's a big freaking gamble. How effective does Github's mitigation need to be to make the costs tolerable? They're already using a full 1% of the traffic to ddos, they can only double that 7 times. Really, at this point Github could probably put together a really nice blacklist of baidu users outside of china, and whitelist those that actually use the service. I can think of a couple of cute ways to accelerate the whitelisting. Banking on Github not finding a good enough solution seems really risky. Why not just ddos every time there's positive Github news? Ideally a half hour in advance of the event? China must know when MS is going to host some cool new project. China must know when the U.S. data service is going to host a cool new project. China must know when Github is going to announce a new feature. This approach is just super half assed.
- rsuelzer 12y agoSide question, does GitHub run ruby on rails? If so, I'm pretty impressed.
- wyaeld 12y agoThey do, but a real ruby on rails site typically serves most html content out of memcache, even higher for users that aren't logged into the platform. Its not unknown to see 5-10ms response times in those scenarios
- pmontra 12y agoThey are on Rails 3 which is pretty old for Rails standards and they got there recently. See http://shayfrendt.com/posts/upgrading-github-to-rails-3-with-zero-downtime/ http://shayfrendt.com/posts/upgrading-github-to-rails-3-with... This is their architecture in 2009 https://github.com/blog/530-how-we-made-github-fast https://github.com/blog/530-how-we-made-github-fast Couldn't find anything more recent.