high_scalability high_scalability-2008 high_scalability-2008-248 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: How do you plan to scale your system as you reach predictable milestones? This topic came up in another venue and it reminded me about a great comment an Anonymous wrote a while ago and I wanted to make sure that comment didn't get lost. The Anonymous scaling plan was relatively simple and direct: My two cents on what I'm using to start a website from scratch using a single server for now. Later, I'll scale out horizontally when the need arises. Phase 1 Single Server, Dual Quad-Core 2.66, 8gb RAM, 500gb Disk Raid 10 OS: Fedora 8. You could go with pretty much any Linux though. I like Fedora 8 best for servers. Proxy Cache: Varnish - it is way faster than Squid per my own benchmarks. Squid chokes bigtime. Web Server: Lighttpd - faster than Apache 2 and easier to configure for me. Object Cache: Memcached. Very scalable. PHP Cache: APC. Easy to configure and seems to work fine. Language: PHP 5 - no bloated frameworks, waste of time for me. You spend too mu
sentIndex sentText sentNum sentScore
1 How do you plan to scale your system as you reach predictable milestones? [sent-1, score-0.469]
2 This topic came up in another venue and it reminded me about a great comment an Anonymous wrote a while ago and I wanted to make sure that comment didn't get lost. [sent-2, score-0.447]
3 The Anonymous scaling plan was relatively simple and direct: My two cents on what I'm using to start a website from scratch using a single server for now. [sent-3, score-0.463]
4 Later, I'll scale out horizontally when the need arises. [sent-4, score-0.33]
5 Web Server: Lighttpd - faster than Apache 2 and easier to configure for me. [sent-11, score-0.224]
6 Phase 2 Max Ram out to 64 GB, cache everything Phase 3 Buy load balancer + 2 more servers for front end Varnish/Memcached/Lighttpd. [sent-21, score-0.303]
7 Phase 4 Depending on my load & usage patterns, scale out the database horizontally with an additional server. [sent-23, score-0.33]
8 I don't expect the db to be a bottleneck for my website as only metadata info is stored there. [sent-24, score-0.15]
9 Possibly separate Varnish / Memcached / Lighttpd tier into separate tiers if necessary. [sent-26, score-0.333]
10 But I'll carefully evaluate the situation at this point and scale out appropriately and use CDN for static content if necessary. [sent-27, score-0.298]
11 I'll scale the individual machines when necessary and scale horizontally too. [sent-31, score-0.461]
12 In previous post we also read where ThemBid has a nice simple scalability plan too : Use Munin to tell when to think about upgrading. [sent-32, score-0.198]
13 When your growth trend will soon cross your resources trend, it's time to do something. [sent-33, score-0.21]
14 What you want to run on this server depend on its capabilities. [sent-36, score-0.19]
15 Move to a distributed memory cache using memcached. [sent-38, score-0.213]
16 If more webservers are needed us LVS on the front end as a load balancer. [sent-40, score-0.185]
17 The great insight ThemBid had was to use monitoring to predict when performance is hitting a limit so you can take action before the world ends. [sent-41, score-0.148]
18 Have a plan in mind for what you want to do when you grow. [sent-45, score-0.198]
19 You don't have to do all now, but make the path easier by starting in the right direction now. [sent-46, score-0.162]
20 You'll also be much less stressed when all hell breaks loose. [sent-47, score-0.268]
wordName wordTfidf (topN-words)
[('fedora', 0.239), ('cache', 0.213), ('horizontally', 0.199), ('plan', 0.198), ('anonymous', 0.187), ('squid', 0.173), ('lighttpd', 0.157), ('varnish', 0.15), ('predictable', 0.14), ('trend', 0.138), ('configure', 0.134), ('thembid', 0.133), ('milestones', 0.133), ('scale', 0.131), ('feedburner', 0.125), ('bloated', 0.125), ('separate', 0.123), ('comment', 0.119), ('mysql', 0.117), ('reminded', 0.111), ('ram', 0.109), ('lvs', 0.108), ('stressed', 0.108), ('server', 0.107), ('frees', 0.101), ('munin', 0.098), ('venue', 0.098), ('webservers', 0.095), ('appropriately', 0.092), ('front', 0.09), ('easier', 0.09), ('tiers', 0.087), ('loose', 0.085), ('pretty', 0.084), ('depend', 0.083), ('cents', 0.082), ('hell', 0.082), ('postgres', 0.079), ('stored', 0.078), ('breaks', 0.078), ('memcached', 0.076), ('scratch', 0.076), ('carefully', 0.075), ('predict', 0.075), ('stage', 0.074), ('hitting', 0.073), ('greatest', 0.073), ('resources', 0.072), ('direction', 0.072), ('info', 0.072)]
simIndex simValue blogId blogTitle
same-blog 1 1.0000002 248 high scalability-2008-02-13-What's your scalability plan?
Introduction: How do you plan to scale your system as you reach predictable milestones? This topic came up in another venue and it reminded me about a great comment an Anonymous wrote a while ago and I wanted to make sure that comment didn't get lost. The Anonymous scaling plan was relatively simple and direct: My two cents on what I'm using to start a website from scratch using a single server for now. Later, I'll scale out horizontally when the need arises. Phase 1 Single Server, Dual Quad-Core 2.66, 8gb RAM, 500gb Disk Raid 10 OS: Fedora 8. You could go with pretty much any Linux though. I like Fedora 8 best for servers. Proxy Cache: Varnish - it is way faster than Squid per my own benchmarks. Squid chokes bigtime. Web Server: Lighttpd - faster than Apache 2 and easier to configure for me. Object Cache: Memcached. Very scalable. PHP Cache: APC. Easy to configure and seems to work fine. Language: PHP 5 - no bloated frameworks, waste of time for me. You spend too mu
2 0.24064074 33 high scalability-2007-07-26-ThemBid Architecture
Introduction: ThemBid provides a market where people needing work done broadcast their request and accept bids from people competing for the job. Unlike many of the sites profiled at HighScalability, ThemBid is not in the popular press as often as Paris Hilton. It's not a media darling or a giant of the industry. But what I like is they have a strategy, a point-of-view for building websites and were gracious enough to share very detailed instructions on how to go about building a website. They even delve into actual installation details of the various software packages they use. Anyone can benefit by taking a look at their work. Site: http://www.thembid.com/ Information Sources Build Scalable Web 2.0 Sites with Ubuntu, Symfony, and Lighttpd Platform Linux (Ubuntu) Symfony Lighttpd PHP eAccelerator Eclipse Munin AWStats What's Inside? The Stats Started work in December of 2006 and had a full demo by March 2007. One developer/sys admin worked with a pa
3 0.19503506 360 high scalability-2008-08-04-A Bunch of Great Strategies for Using Memcached and MySQL Better Together
Introduction: The primero recommendation for speeding up a website is almost always to add cache and more cache. And after that add a little more cache just in case. Memcached is almost always given as the recommended cache to use. What we don't often hear is how to effectively use a cache in our own products. MySQL hosted two excellent webinars (referenced below) on the subject of how to deploy and use memcached. The star of the show, other than MySQL of course, is Farhan Mashraqi of Fotolog. You may recall we did an earlier article on Fotolog in Secrets to Fotolog's Scaling Success , which was one of my personal favorites. Fotolog, as they themselves point out, is probably the largest site nobody has ever heard of, pulling in more page views than even Flickr. Fotolog has 51 instances of memcached on 21 servers with 175G in use and 254G available. As a large successful photo-blogging site they have very demanding performance and scaling requirements. To meet those requirements they've developed a
4 0.1743245 884 high scalability-2010-08-23-6 Ways to Kill Your Servers - Learning How to Scale the Hard Way
Introduction: This is a guest post by Steffen Konerow, author of the High Performance Blog . Learning how to scale isn’t easy without any prior experience. Nowadays you have plenty of websites like highscalability.com to get some inspiration, but unfortunately there is no solution that fits all websites and needs. You still have to think on your own to find a concept that works for your requirements. So did I. A few years ago, my bosses came to me and said “We’ve got a new project for you. It’s the relaunch of a website that has already 1 million users a month. You have to build the website and make sure we’ll be able to grow afterwards”. I was already an experienced coder, but not in these dimensions, so I had to start learning how to scale – the hard way. The software behind the website was a PHP content management system, based on Smarty and MySQL. The first task was finding a proper hosting company who had the experience and would also manage the servers for us. After some researc
5 0.16850686 1321 high scalability-2012-09-12-Using Varnish for Paywalls: Moving Logic to the Edge
Introduction: This is a guest post from Per Buer , founder and CEO of Varnish Software , provider of Varnish Cache, an open source web application accelerator freely available at varnish-cache.org . Varnish powers a lot of really big websites worldwide. We at Varnish Software are all about speed. Varnish Cache is built for speed. It executes its policy code more or less a thousand times faster than your typical Java or PHP based application servers, mostly due to the fact that the configuration is compiled into system call free machine code. System calls require expensive context switches, stall the CPU and wreck havoc in the CPU cache so avoiding them makes the code fly. There are strong limitations on what kind of logic you can move into Varnish Cache, but the logic that you do move there will run very fast. An example is using Varnish for access control to serve access controlled content from the caching edge layer. The Varnish Paywall Who gets to access your content? In a tradi
6 0.16738586 662 high scalability-2009-07-27-Handle 700 Percent More Requests Using Squid and APC Cache
7 0.16519539 72 high scalability-2007-08-22-Wikimedia architecture
8 0.14635938 274 high scalability-2008-03-12-YouTube Architecture
9 0.14396867 538 high scalability-2009-03-16-Are Cloud Based Memory Architectures the Next Big Thing?
10 0.1409896 467 high scalability-2008-12-16-[ANN] New Open Source Cache System
11 0.14088805 313 high scalability-2008-05-02-Friends for Sale Architecture - A 300 Million Page View-Month Facebook RoR App
12 0.13943726 152 high scalability-2007-11-13-Flickr Architecture
13 0.13821399 74 high scalability-2007-08-23-Product: Varnish
14 0.13764232 996 high scalability-2011-02-28-A Practical Guide to Varnish - Why Varnish Matters
15 0.13397323 808 high scalability-2010-04-12-Poppen.de Architecture
16 0.13257048 136 high scalability-2007-10-28-Scaling Early Stage Startups
17 0.1249026 1508 high scalability-2013-08-28-Sean Hull's 20 Biggest Bottlenecks that Reduce and Slow Down Scalability
18 0.12439098 7 high scalability-2007-07-12-FeedBurner Architecture
19 0.1223226 920 high scalability-2010-10-15-Troubles with Sharding - What can we learn from the Foursquare Incident?
20 0.12228525 134 high scalability-2007-10-26-Paper: Wikipedia's Site Internals, Configuration, Code Examples and Management Issues
topicId topicWeight
[(0, 0.231), (1, 0.097), (2, -0.08), (3, -0.182), (4, -0.012), (5, 0.028), (6, -0.018), (7, -0.039), (8, -0.029), (9, -0.008), (10, -0.07), (11, -0.093), (12, 0.028), (13, 0.115), (14, -0.048), (15, -0.062), (16, -0.021), (17, 0.01), (18, -0.032), (19, 0.03), (20, -0.085), (21, 0.05), (22, 0.014), (23, 0.028), (24, 0.021), (25, 0.076), (26, 0.101), (27, -0.009), (28, -0.043), (29, -0.025), (30, -0.011), (31, 0.022), (32, -0.023), (33, 0.024), (34, -0.03), (35, -0.007), (36, -0.054), (37, 0.0), (38, 0.02), (39, 0.029), (40, 0.002), (41, -0.015), (42, -0.027), (43, -0.016), (44, -0.062), (45, 0.04), (46, -0.053), (47, 0.018), (48, 0.02), (49, -0.08)]
simIndex simValue blogId blogTitle
same-blog 1 0.97683722 248 high scalability-2008-02-13-What's your scalability plan?
Introduction: How do you plan to scale your system as you reach predictable milestones? This topic came up in another venue and it reminded me about a great comment an Anonymous wrote a while ago and I wanted to make sure that comment didn't get lost. The Anonymous scaling plan was relatively simple and direct: My two cents on what I'm using to start a website from scratch using a single server for now. Later, I'll scale out horizontally when the need arises. Phase 1 Single Server, Dual Quad-Core 2.66, 8gb RAM, 500gb Disk Raid 10 OS: Fedora 8. You could go with pretty much any Linux though. I like Fedora 8 best for servers. Proxy Cache: Varnish - it is way faster than Squid per my own benchmarks. Squid chokes bigtime. Web Server: Lighttpd - faster than Apache 2 and easier to configure for me. Object Cache: Memcached. Very scalable. PHP Cache: APC. Easy to configure and seems to work fine. Language: PHP 5 - no bloated frameworks, waste of time for me. You spend too mu
2 0.81296188 602 high scalability-2009-05-17-Scaling Django Web Apps by Mike Malone
Introduction: Film buffs will recognize Django as a classic 1966 spaghetti western that spawned hundreds of imitators. Web heads will certainly first think of Django as the classic Python based Web framework that has also spawned hundreds of imitators and has become the gold standard framework for the web. Mike Malone, who worked on Pownce, a blogging tool now owned by Six Apart, tells in this very informative EuroDjangoCon presentation how Pownce scaled using Django in the real world. I was surprised to learn how large Pounce was: hundreds of requests/sec, thousands of DB operations/sec, millions of user relationships, millions of notes, and terabytes of static data. Django has a lot of functionality in the box to help you scale, but if you want to scale large it turns out Django has some limitations and Mike tells you what these are and also provides some code to get around them. Mike's talk-although Django specific--will really help anyone creating applications on the web. There's
3 0.79477465 360 high scalability-2008-08-04-A Bunch of Great Strategies for Using Memcached and MySQL Better Together
Introduction: The primero recommendation for speeding up a website is almost always to add cache and more cache. And after that add a little more cache just in case. Memcached is almost always given as the recommended cache to use. What we don't often hear is how to effectively use a cache in our own products. MySQL hosted two excellent webinars (referenced below) on the subject of how to deploy and use memcached. The star of the show, other than MySQL of course, is Farhan Mashraqi of Fotolog. You may recall we did an earlier article on Fotolog in Secrets to Fotolog's Scaling Success , which was one of my personal favorites. Fotolog, as they themselves point out, is probably the largest site nobody has ever heard of, pulling in more page views than even Flickr. Fotolog has 51 instances of memcached on 21 servers with 175G in use and 254G available. As a large successful photo-blogging site they have very demanding performance and scaling requirements. To meet those requirements they've developed a
4 0.79347187 911 high scalability-2010-09-30-More Troubles with Caching
Introduction: As a tasty pairing with Facebook And Site Failures Caused By Complex, Weakly Interacting, Layered Systems , is another excellent tale of caching gone wrong by Peter Zaitsev, in an exciting twin billing: Cache Miss Storm and More on dangers of the caches . This is fascinating case where the cause turned out to be software upgrade that ran long because it had to be rolled back. During the long recovery time many of the cache entries timed out. When the database came back, slam, all the clients queried the database to repopulate the cache and bad things happened to the database. The solution was equally interesting: So the immediate solution to bring the system up was surprisingly simple. We just had to get traffic on the system in stages allowing Memcache to be warmed up. There were no code which would allow to do it on application side so we did it on MySQL side instead. “SET GLOBAL max_connections=20” to limit number of connections to MySQL and so let application to err when i
5 0.78182012 884 high scalability-2010-08-23-6 Ways to Kill Your Servers - Learning How to Scale the Hard Way
Introduction: This is a guest post by Steffen Konerow, author of the High Performance Blog . Learning how to scale isn’t easy without any prior experience. Nowadays you have plenty of websites like highscalability.com to get some inspiration, but unfortunately there is no solution that fits all websites and needs. You still have to think on your own to find a concept that works for your requirements. So did I. A few years ago, my bosses came to me and said “We’ve got a new project for you. It’s the relaunch of a website that has already 1 million users a month. You have to build the website and make sure we’ll be able to grow afterwards”. I was already an experienced coder, but not in these dimensions, so I had to start learning how to scale – the hard way. The software behind the website was a PHP content management system, based on Smarty and MySQL. The first task was finding a proper hosting company who had the experience and would also manage the servers for us. After some researc
6 0.77951354 174 high scalability-2007-12-05-Product: Tugela Cache
7 0.77051282 302 high scalability-2008-04-10-Mysql scalability and failover...
8 0.76070952 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier
9 0.75475639 33 high scalability-2007-07-26-ThemBid Architecture
10 0.75322002 1321 high scalability-2012-09-12-Using Varnish for Paywalls: Moving Logic to the Edge
11 0.74645585 247 high scalability-2008-02-12-We want to cache a lot :) How do we go about it ?
12 0.74168849 136 high scalability-2007-10-28-Scaling Early Stage Startups
13 0.73934931 808 high scalability-2010-04-12-Poppen.de Architecture
14 0.73762518 312 high scalability-2008-04-30-Rather small site architecture.
15 0.73481482 149 high scalability-2007-11-12-Scaling Using Cache Farms and Read Pooling
16 0.7312234 1620 high scalability-2014-03-27-Strategy: Cache Stored Procedure Results
17 0.72921705 996 high scalability-2011-02-28-A Practical Guide to Varnish - Why Varnish Matters
18 0.7262733 662 high scalability-2009-07-27-Handle 700 Percent More Requests Using Squid and APC Cache
19 0.71519911 1486 high scalability-2013-07-03-5 Rockin' Tips for Scaling PHP to 30,000 Concurrent Users Per Server
20 0.71346164 1633 high scalability-2014-04-16-Six Lessons Learned the Hard Way About Scaling a Million User System
topicId topicWeight
[(1, 0.106), (2, 0.269), (3, 0.066), (10, 0.038), (23, 0.011), (30, 0.042), (47, 0.033), (61, 0.115), (73, 0.026), (77, 0.017), (79, 0.113), (85, 0.062), (94, 0.03)]
simIndex simValue blogId blogTitle
same-blog 1 0.96846247 248 high scalability-2008-02-13-What's your scalability plan?
Introduction: How do you plan to scale your system as you reach predictable milestones? This topic came up in another venue and it reminded me about a great comment an Anonymous wrote a while ago and I wanted to make sure that comment didn't get lost. The Anonymous scaling plan was relatively simple and direct: My two cents on what I'm using to start a website from scratch using a single server for now. Later, I'll scale out horizontally when the need arises. Phase 1 Single Server, Dual Quad-Core 2.66, 8gb RAM, 500gb Disk Raid 10 OS: Fedora 8. You could go with pretty much any Linux though. I like Fedora 8 best for servers. Proxy Cache: Varnish - it is way faster than Squid per my own benchmarks. Squid chokes bigtime. Web Server: Lighttpd - faster than Apache 2 and easier to configure for me. Object Cache: Memcached. Very scalable. PHP Cache: APC. Easy to configure and seems to work fine. Language: PHP 5 - no bloated frameworks, waste of time for me. You spend too mu
2 0.9678238 189 high scalability-2007-12-21-Strategy: Limit Result Sets
Introduction: Release It! author Michael Nygard tells a tale of two web sites , both brought low by unexpectedly huge unbounded results sets that slowed down their sites to the speed of a Christmas checkout line. I've committed this error more than a few times. During testing the results sets are often small, so you don't see problems. Or when a product is new you don't have a lot of data so everything is fine, until some magic line is crossed and you get that dreaded 2AM fix it call. My most embarrassing bug of this type caused a rather spectacular failure at a customer site as the variance in response times was out of spec and this kicked in penalty clauses. What happened was the customer had a larger network than we could even test (customers always get the good stuff). I took a lock and went to get all the data. Because the result set was so much larger in their larger system I took the lock for many more milliseconds than I should have. Unknown to me a chunk of code on the criti
3 0.96432972 628 high scalability-2009-06-13-Neo4j - a Graph Database that Kicks Buttox
Introduction: Update: Social networks in the database: using a graph database . A nice post on representing, traversing, and performing other common social network operations using a graph database. If you are Digg or LinkedIn you can build your own speedy graph database to represent your complex social network relationships. For those of more modest means Neo4j , a graph database, is a good alternative. A graph is a collection nodes (things) and edges (relationships) that connect pairs of nodes. Slap properties (key-value pairs) on nodes and relationships and you have a surprisingly powerful way to represent most anything you can think of. In a graph database "relationships are first-class citizens. They connect two nodes and both nodes and relationships can hold an arbitrary amount of key-value pairs. So you can look at a graph database as a key-value store, with full support for relationships." A graph looks something like: For more lovely examples take a look at the Graph Image Gal
4 0.96419817 714 high scalability-2009-10-02-HighScalability has Moved to Squarespace.com!
Introduction: You may have noticed something is a little a different when visiting HighScalability today: We've Moved! HighScalability.com has switched hosting services to Squarespace.com. House warming gifts are completely unnecessary. Thanks for the thought though. It's been a long long long process. Importing a largish Drupal site to Wordpress and then into Squarespace is a bit like dental work without the happy juice, but the results are worth it. While the site is missing a few features I think it looks nicer, feels faster, and I'm betting it will be more scalable and more reliable. All good things. I'll explain more about the move later in this post, but there's some admistrivia that needs to be handled to make the move complete: If you have a user account and have posted on HighScalability before then you have a user account, but since I don't know your passwords I had to make new passwords up for you. So please contact me and I'll give you your password so you can login and change it.
5 0.96297091 554 high scalability-2009-04-04-Digg Architecture
Introduction: Update 4: : Introducing Digg’s IDDB Infrastructure by Joe Stump. IDDB is a way to partition both indexes (e.g. integer sequences and unique character indexes) and actual tables across multiple storage servers (MySQL and MemcacheDB are currently supported with more to follow). Update 3: : Scaling Digg and Other Web Applications . Update 2: : How Digg Works and How Digg Really Works (wear ear plugs). Brought to you straight from Digg's blog. A very succinct explanation of the major elements of the Digg architecture while tracing a request through the system. I've updated this profile with the new information. Update: Digg now receives 230 million plus page views per month and 26 million unique visitors - traffic that necessitated major internal upgrades . Traffic generated by Digg's over 22 million famously info-hungry users and 230 million page views can crash an unsuspecting website head-on into its CPU, memory, and bandwidth limits. How does Digg handle billions of req
6 0.96202719 365 high scalability-2008-08-16-Strategy: Serve Pre-generated Static Files Instead Of Dynamic Pages
8 0.9619149 1215 high scalability-2012-03-26-7 Years of YouTube Scalability Lessons in 30 Minutes
9 0.96182346 1020 high scalability-2011-04-12-Caching and Processing 2TB Mozilla Crash Reports in memory with Hazelcast
10 0.96164697 672 high scalability-2009-08-06-An Unorthodox Approach to Database Design : The Coming of the Shard
11 0.96124661 1178 high scalability-2012-01-20-Stuff The Internet Says On Scalability For January 20, 2012
12 0.96106011 1065 high scalability-2011-06-21-Running TPC-C on MySQL-RDS
13 0.96094608 589 high scalability-2009-05-05-Drop ACID and Think About Data
14 0.96075261 943 high scalability-2010-11-16-Facebook's New Real-time Messaging System: HBase to Store 135+ Billion Messages a Month
15 0.96048427 1255 high scalability-2012-06-01-Stuff The Internet Says On Scalability For June 1, 2012
16 0.96022105 1509 high scalability-2013-08-30-Stuff The Internet Says On Scalability For August 30, 2013
17 0.95992434 1017 high scalability-2011-04-06-Netflix: Run Consistency Checkers All the time to Fixup Transactions
18 0.95991749 1074 high scalability-2011-07-06-11 Common Web Use Cases Solved in Redis
19 0.95986569 661 high scalability-2009-07-25-Latency is Everywhere and it Costs You Sales - How to Crush it
20 0.95946068 825 high scalability-2010-05-10-Sify.com Architecture - A Portal at 3900 Requests Per Second