Hard to know for sure, but most of the problems would have been exposed at even moderate amounts of load--there was no load testing or performance monitoring in place initially.
back
1 comments
Java in production, especially with heavy "frameworks" use and "waterfall to subcontracted coders-for-paycheck" process (how else there could be a billion lines of code for a site) can't handle even a moderate load and runs out of memory on handling persistent connections (long sessions) and the fixes were mostly by adding tons of hardware (unlimited government money) and to redesign many components to share nothing (decoupling) and to work in asynchronous way with a short requests (service-oriented architecture + Erlang's process-based model) by Google, FB, etc. guys? That's the story?
btw, these are very legitimate questions. The original project was a epic failure which perfectly illustrated all the flaws of past-century practices (waterfall process with tons of specs created by idiots, outsourcing to the cheapest or favorite incompetent, blind faith in big names, etc.) and the fix, it seems, was to bring it close to the state-of-the-art tech which was evolved to use-at-home in [more-or-less] independent-thinking shops, like Google or FB.