I want to show that the notion of scalability is every bit as valid when applied to programming languages as it is when applied to programs or algorithms. I'll also discuss several well-known and not so well-known programming languages from this perspective and give some concrete recommendations, as well as discuss some of the social factors which hinder progress in this field.
Red Hat on Wednesday announced a significant departure from its current business plan, saying its flagship Linux product will be available on Amazon.com's Elastic Computing Cloud online service.
Google Maps, Yahoo! Mail, Facebook, MySpace, YouTube, and Amazon are examples of Web sites built to scale. They access petabytes of data sending terabits per second to millions of users worldwide. The magnitude is awe-inspiring. Users view these large-scale Web sites from a narrower perspective. The typical user has megabytes of data that are downloaded at a few hundred kilobits per second. Users are not so interested in the massive number of requests per second being served; they care more about their individual requests. As they use these Web applications, they inevitably ask the same question: "Why is this site so slow?" The answer hinges on where development teams focus their performance improvements. Performance for the sake of scalability is rightly focused on the back end. Database tuning, replicating architectures, customized data caching, and so on allow Web servers to handle a greater number of requests.
James Hamilton has published a thorough summary of Facebook's Cassandra, another scalable key-value store for your perusal. It's open source and is described as a "BigTable data model running on a Dynamo-like infrastructure." Cassandra is used in Facebook as an email search system containing 25TB and over 100m mailboxes. # Google Code for Cassandra - A Structured Storage System on a P2P Network # SIGMOD 2008 Presentation. # Video Presentation at Facebook # Facebook Engineering Blog for Cassandra # Anti-RDBMS: A list of distributed key-value stores # Facebook Cassandra Architecture and Design by James Hamilton
February 17th, 2008 A 'problem' with the Mongrel/Rails platform A request comes in to the web server, and if it's dynamic, falls down to a waiting mongrel process. Mongrel calls Rails which wraps a big lock around most of the request/response cycle so the mongrel thats serving the request has to wait for a response from Rails to unlock and start serving other requests. This is the Blocked Thread stability anti-pattern that Michael Nygard talks about in Release It!. The problem is that Nginx or Apache doesn't know that a mongrel is blocked and keeps blindly sending requests. Thats means that even a single blocked mongrel will result in some slow responses for requests that come in to that same mongrel. Cut the Request Fat And one way to do that is to use the "Skinny Request, Fat Backend" principle. What that means in practical terms is pretty simple: Do as little as possible inside of the Request/Response cycle.
R. Ondas, M. Pelikan, and K. Sastry. GECCO 2005: Proceedings of the 2005 conference on
Genetic and evolutionary computation, 2, page 1785--1786. Washington DC, USA, ACM Press, (25-29 June 2005)
M. Bilal, and S. Kang. (2017)cite arxiv:1704.02683Comment: This article is accepted for the publication in Cluster Computing-The Journal of Networks, Software Tools and Applications. Print ISSN 1386-7857, Online ISSN 1573-7543.