August 25th, 2008
Update: Dan Pritchett shares some excellent
Sharding Lessons: Size Your Shards, Use Math on
Shard Counts, Carefully Consider the Spread, Plan for Exceeding Your Shards
Once upon a time we scaled databases by buying ever bigger, faster, and more expensive machines. While this arrangement is great for big iron profit margins, it doesn't work so well for the bank accounts of our heroic system builders who need to scale well past what they can afford to spend on giant database servers. In a extraordinary two article series, Dathan Pattishall, explains his motivation for a revolutionary new database architecture--sharding--that he began thinking about even before he worked at Friendster, and fully implemented at Flickr. Flickr now handles more than 1 billion transactions per day, responding in less then a few seconds and can scale linearly at a low cost.
What is sharding and how has it come to be the answer to large website scaling problems?
read more
Posted in Scalability | Comments Off
August 24th, 2008
Looks interesting...
Abstract:
Today’s data centers may contain tens of thousands of computers with significant aggregate bandwidth requirements. The network architecture typically consists of a tree of routing and switching elements with progressively more specialized and expensive equipment moving up the network hierarchy. Unfortunately, even when deploying the highest-end IP switches/routers, resulting topologies may only support 50% of the aggregate bandwidth available at the edge of the network, while still incurring tremendous cost. Nonuniform bandwidth among data center nodes complicates application design and limits overall system performance.
In this paper, we show how to leverage largely commodity Ethernet switches to support the full aggregate bandwidth of clusters consisting of tens of thousands of elements. Similar to how clusters of commodity computers have largely replaced more specialized SMPs and MPPs, we argue that appropriately architected and interconnected commodity switches may deliver more performance at less cost than available from today’s higher-end solutions. Our approach requires no modifications to the end host network interface, operating system, or applications; critically, it is fully backward compatible with Ethernet, IP, and TCP.
Posted in Scalability | Comments Off
August 16th, 2008
Pre-generating static files is an oldy but a goody, and as Thomas Brox Røst says, it's probably an underused strategy today. At one time this was the dominate technique for structuring a web site. Then the age of dynamic web sites arrived and we spent all our time worrying how to make the database faster and add more caching to recover the speed we had lost in the transition from static to dynamic.
Static files have the advantage of being very fast to serve. Read from disk and display. Simple and fast. Especially when caching proxies are used. The issue is how do you bulk generate the initial files, how do you serve the files, and how do you keep the changed files up to date? This is the process Thomas covers in his excellent article
Serving static files with Django and AWS - going fast on a budget", where he explains how he converted 600K thousand previously dynamic pages to static pages for his site
Eventseer.net, a service for tracking academic events.
Eventseer.net was experiencing performance problems as search engines crawled their 600K dynamic pages. As a solution you could imagine scaling up, adding more servers, adding sharding, etc etc, all somewhat complicated approaches. Their solution was to convert the dynamic pages to static pages in order to keep search engines from killing the site. As an added bonus non logged-in users experienced a much faster site and were more likely to sign up for the service.
The article does a good job explaining what they did, so I won't regurgitate it all here, but I will cover the highlights and comment on some additional potential features and alternate implementations...
read more Posted in Scalability | Comments Off
August 15th, 2008
Posted in Virtualization | Comments Off
July 21st, 2008
Posted in Virtualization | Comments Off
June 30th, 2008
It seems that everyone on the blogosphere, including Divmod, is talking about “scaling” these days. I’d like to talk a bit about what we mean — and by “we” I mean both the Twisted community and Divmod, Inc., — when we talk about “scaling”.
[more]
One of the issues that I continually deal with is the scaling of an application and its platform. I believe this author makes the point rather well.
Posted in Scalability | No Comments »
June 29th, 2008
Posted in Virtualization | Comments Off
June 29th, 2008
Posted in Virtualization | Comments Off
June 27th, 2008
156 hours.
That’s what it took to track down a solution to a problem with some Open Source software. The software was written in the early 2000 time frame, the last documentation update was in 2006. The scenario that we were designing was documented on a page written in 2004.
The issue we ran into must be something that someone else has stumbled into because it is a very basic piece of the operation of this piece of software, but, in perusing all of the available documentation, using google to find any possible references, looking through all FAQs, committed code, mailing lists, etc. the solution presented itself on a page last updated in January of 2000.
A three line mention.
That’s it.
The author of the FAQ written in 2004 that describes the process and documents every step save for one very important part. The three line mention in another FAQ, coincidentally written by the FAQ author in an email that was sent to a mailing list and included in someone else’s FAQ.
This is the inherent cost in Open Source.
We’re not using this software in an odd manner — in fact, the feature we were trying to use is one of the three fundamental uses. The software hasn’t changed much in the last 4 years, but, it just goes to show you that documentation is easily forgotton in the Open Source world.
Would I have it any other way? No. I prefer open source because we can develop solutions that give us a competitive edge, and, if we need to, we can change the code to fix problems that the developers won’t fix.
Often times our requirements are based on a business case which conflicts with some of the purist open source coders.
Posted in Web Infrastructure | No Comments »
June 26th, 2008
Posted in Virtualization | Comments Off
