8/14/2019 How Digg com uses the LAMP stack to scale upward

1/2

How Digg.com uses the LAMP stack to scale upward http://www.computerworld.com/action/article.do?command=printA

of 2 5/29/07 11:23

How Digg.com uses the LAMP stack to scale upwardEric Lai

April 24, 2007 (Computerworld)Digg.com credits two particular features of its LAMP (Linux, Apache, MySQL andPHP) server cluster for helping the news aggregation site maintain speedy performance in the face of high growth.

The site, which lets its users vote on, or "digg," their favorite news stories hosted on other sites, recently passed the 1.2million-user mark according to Elliot White III, an engineer at San Francisco-based Digg Inc. He spoke at MySQLsannual conference in Santa Clara, Calif. on Tuesday.

Today, Digg.com boasts 100 servers scattered in multiple data centers that host a total of 30GB of data, but the site

started off in late 2004 as a single Linux server running Apache 1.3, PHP 4, and MySQL 4.0 using thedefault MyISAM storage engine, White said.

As more users dug Digg, the site moved to anarchitecture that uses a load balancer in thefront that sends queries to PHP servers,MySQL slave servers that feed the PHPservers, and a MySQL master server that feedsdata to the slaves.

That's a fairly standard setup. But to get awayfrom "sending raw queries against thedatabase," White said Digg.com uses asoftware called Memcached. First developedfor use by the Livejournal site, Memcached istailored for dynamic sites like Digg.com, whichserve Web pages with content that is constantlychanging and is personalized according to user

preferences, White said.

Memcached stores chunks of data that can bepulled and used to dynamically create a Webpage. Conventional caching systems, whichstore whole Web pages, would be too slow andinefficient for a site like Digg.

The other atypical feature of Diggs setup is itsuse of what Tim Ellis, another Digg engineer,calls "sharding."

A term apparently coined by Google engineers, sharding involves breaking a database into smaller parts in order toisolate heavy loads for better performance.

"If 90% of your data is within a certain range, and you can get that part working really fast, then you can helpcustomers," Ellis said. "Then its OK if the remaining 10% is slower."

A database can be sharded by table, date or range. It is similar to partitioning, says Ellis, but with several keydifferences. Sharding usually involves divvying up data onto different physical machines. Partitioning, in contrast,typically occurs on the same piece of hardware. And while MySQL does not natively allow sharding, it does supportpartitioned tables, federated tables and clusters.

Digg only recently began sharding. While sharding is helping Digg.com achieve much faster performance overall,breaking a database into several smaller ones increases complexity, Ellis said. That can mean more work fordevelopers and database administrators, because of the inability to use common SQL commands such as joiningtables. "Developers dont like this crazy stuff. That can create pushback," he said.

Diggs current architecture includes about 20 database servers, 30 Web servers, and a few search serversrunning Lucene; the balance operate as backup servers. All but one of the database servers run some version of

8/14/2019 How Digg com uses the LAMP stack to scale upward

2/2

How Digg.com uses the LAMP stack to scale upward http://www.computerworld.com/action/article.do?command=printA

of 2 5/29/07 11:23

MySQL 5. The transaction-heavy servers as well as the backup units use the InnoDB database engine, while the OLAPones use MyISAM.

Ellis acknowledges that Digg.com "is really lucky" in that 98% of the time the database is accessed, it is being read, asopposed to experiencing more intensive data writes.

"Most people come to Diggs front page, read it and leave, which is kind of nice," said Ellis, drawing a knowing laughfrom the audience of mostly PHP developers and DBAs.

Ellis also noted that although many users have complained that upgrading to MySQL 5 from 4.1 caused performance todrop, that was not true in Digg.coms case.

Maintaining Digg.com's high performance as the site grows more and more popular presents challenges to Diggengineers. For one thing, the company is unable to keep scaling by buying more physical memory. "We cant afford thatanymore," Ellis said.

Preventing Diggs enthusiastic developers from adding powerful but CPU-intensive features is "a political thing Iconstantly have to deal with as a DBA," said Ellis.

Also, Digg was having a problem with its storage misreporting the status of data synchronizations. "Our hardwarewanted to be fast," Ellis said. "It was telling us things were synced to disk when it was not."

Finally, there is the mundane challenge of minimizing "schema cruft," or redundant tables of data which, if read, canslow down performance, said Ellis.

"Everyone has to do this," he said.