high_scalability high_scalability-2010 high_scalability-2010-911 knowledge-graph by maker-knowledge-mining
Source: html
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
sentIndex sentText sentNum sentScore
1 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 . [sent-1, score-1.005]
2 This is fascinating case where the cause turned out to be software upgrade that ran long because it had to be rolled back. [sent-2, score-0.413]
3 During the long recovery time many of the cache entries timed out. [sent-3, score-0.665]
4 When the database came back, slam, all the clients queried the database to repopulate the cache and bad things happened to the database. [sent-4, score-0.698]
5 The solution was equally interesting: So the immediate solution to bring the system up was surprisingly simple. [sent-5, score-0.389]
6 We just had to get traffic on the system in stages allowing Memcache to be warmed up. [sent-6, score-0.407]
7 There were no code which would allow to do it on application side so we did it on MySQL side instead. [sent-7, score-0.228]
8 “SET GLOBAL max_connections=20” to limit number of connections to MySQL and so let application to err when it tries to put too much load on MySQL as MySQL load stabilizes increasing number of connections higher until you finally can serve all traffic without problems. [sent-8, score-0.575]
wordName wordTfidf (topN-words)
[('cache', 0.292), ('miss', 0.216), ('repopulate', 0.183), ('weakly', 0.172), ('pairing', 0.172), ('warmed', 0.164), ('zaitsev', 0.164), ('twin', 0.164), ('mysql', 0.16), ('slam', 0.153), ('dangers', 0.153), ('items', 0.149), ('timed', 0.145), ('tasty', 0.139), ('traffic', 0.134), ('queried', 0.132), ('layered', 0.13), ('connections', 0.128), ('rollback', 0.128), ('gradually', 0.124), ('tale', 0.123), ('long', 0.12), ('suggested', 0.119), ('equally', 0.117), ('interacting', 0.117), ('side', 0.114), ('rolled', 0.11), ('smarter', 0.109), ('stages', 0.109), ('entries', 0.108), ('tries', 0.103), ('peter', 0.101), ('cold', 0.101), ('immediate', 0.099), ('behavior', 0.097), ('surprisingly', 0.093), ('ran', 0.092), ('case', 0.091), ('helpful', 0.091), ('happened', 0.091), ('maintenance', 0.088), ('watch', 0.088), ('exciting', 0.088), ('frequently', 0.086), ('gone', 0.084), ('caused', 0.082), ('accessed', 0.082), ('finally', 0.082), ('caches', 0.082), ('solution', 0.08)]
simIndex simValue blogId blogTitle
same-blog 1 1.0000001 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
2 0.19969411 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
3 0.14729859 495 high scalability-2009-01-17-Intro to Caching,Caching algorithms and caching frameworks part 1
Introduction: Informative and well organized post on caching . Talks about: Why do we need cache?, What is Cache?, Cache Hit, Cache Miss, Storage Cost, Retrieval Cost, Invalidation, Replacement Policy, Optimal Replacement Policy, Caching Algorithms, Least Frequently Used (LFU), Least Recently Used (LRU), Least Recently Used 2(LRU2), Two Queues, Adaptive Replacement Cache (ACR), Most Recently Used (MRU), First in First out (FIFO), Distributed caching, Measuring Cache.
4 0.14447221 436 high scalability-2008-11-02-Strategy: How to Manage Sessions Using Memcached
Introduction: Dormando shows an enlightened middle way for storing sessions in cache and the database. Sessions are a perfect cache candidate because they are transient, smallish, and since they are usually accessed on every page access removing all that load from the database is a good thing. But as Dormando points out session caches have problems. If you remove expiration times from the cache and you run out of memory then no more logins. If a cache server fails or needs to be upgrade then you just logged out a bunch of potentially angry users. The middle ground Dormando proposes is using both the cache and the database: Reads : read from the cache first, then the database. Typical cache logic. Writes : write to memcached every time, write to the database every N seconds (assuming the data has changed). There's a small chance of data loss, but you've still greatly reduced the database load while providing reliability. Nice solution.
5 0.13886049 836 high scalability-2010-06-04-Strategy: Cache Larger Chunks - Cache Hit Rate is a Bad Indicator
Introduction: Isn't the secret to fast, scalable websites to cache everything ? Caching, if not the secret sauce of many a website, is it at least a popular condiment. But not so fast says Peter Zaitsev in Beyond great cache hit ratio . The point Peter makes is that we read about websites like Amazon and Facebook that can literally make hundreds of calls to satisfy a user request. Even if you have an awesome cache hit ratio, pages can still be slow because making and processing all those requests takes time. The solution is to remove requests all together . You do this by caching larger blocks so you have to make fewer requests. The post has a lot of good advice worth reading: 1) Make non cacheable blocks as small as possible, 2) Maximize amount of uses of the cache item, 3) Control invalidation, 4) Multi-Get.
8 0.12496663 467 high scalability-2008-12-16-[ANN] New Open Source Cache System
9 0.12132788 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier
10 0.12079987 359 high scalability-2008-07-29-Ehcache - A Java Distributed Cache
11 0.11964408 673 high scalability-2009-08-07-Strategy: Break Up the Memcache Dog Pile
12 0.11680092 1633 high scalability-2014-04-16-Six Lessons Learned the Hard Way About Scaling a Million User System
13 0.11239963 662 high scalability-2009-07-27-Handle 700 Percent More Requests Using Squid and APC Cache
14 0.10657493 1508 high scalability-2013-08-28-Sean Hull's 20 Biggest Bottlenecks that Reduce and Slow Down Scalability
15 0.10524438 248 high scalability-2008-02-13-What's your scalability plan?
16 0.10340668 577 high scalability-2009-04-22-Gear6 Web cache - the hardware solution for working with Memcache
17 0.10089607 927 high scalability-2010-10-26-Marrying memcached and NoSQL
18 0.10076548 196 high scalability-2007-12-30-MySQL clustering strategies and comparisions
19 0.099784203 252 high scalability-2008-02-18-limit on the number of databases open
20 0.095767304 884 high scalability-2010-08-23-6 Ways to Kill Your Servers - Learning How to Scale the Hard Way
topicId topicWeight
[(0, 0.147), (1, 0.081), (2, -0.07), (3, -0.117), (4, 0.006), (5, 0.047), (6, -0.006), (7, -0.02), (8, -0.061), (9, -0.054), (10, -0.043), (11, -0.036), (12, 0.025), (13, 0.108), (14, -0.073), (15, -0.051), (16, -0.007), (17, -0.034), (18, 0.023), (19, -0.018), (20, -0.032), (21, 0.062), (22, 0.036), (23, 0.07), (24, -0.056), (25, 0.1), (26, -0.022), (27, 0.08), (28, 0.04), (29, -0.037), (30, -0.046), (31, 0.024), (32, -0.018), (33, 0.035), (34, -0.024), (35, 0.057), (36, 0.009), (37, -0.002), (38, 0.048), (39, 0.024), (40, 0.071), (41, -0.018), (42, -0.027), (43, 0.008), (44, -0.032), (45, 0.007), (46, -0.071), (47, 0.05), (48, -0.04), (49, -0.045)]
simIndex simValue blogId blogTitle
same-blog 1 0.98606789 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
2 0.84127623 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
3 0.80074674 673 high scalability-2009-08-07-Strategy: Break Up the Memcache Dog Pile
Introduction: Update: Asynchronous HTTP cache validations . A proposed HTTP caching extension: if your application can afford to show slightly out of date content, then stale-while-revalidate can guarantee that the user will always be served directly from the cache, hence guaranteeing a consistent response-time user-experience. Caching is like aspirin for headaches. Head hurts: pop a 'sprin. Slow site: add caching. Facebook must have a lot of headaches because they popped 805 memcached servers between 10,000 web servers and 1,800 MySQL servers and they reportedly have a 99% cache hit rate. But what's the best way for you to cache for your application? It's a remarkably complex and rich topic. Alexey Kovyrin talks about one common caching problem called the Dog Pile Effect in Dog-pile Effect and How to Avoid it with Ruby on Rails . Glenn Franxman also has a Django solution in MintCache . Data is usually cached because it's too expensive to calculate for every hit. Maybe it's a gnarly S
4 0.79481155 495 high scalability-2009-01-17-Intro to Caching,Caching algorithms and caching frameworks part 1
Introduction: Informative and well organized post on caching . Talks about: Why do we need cache?, What is Cache?, Cache Hit, Cache Miss, Storage Cost, Retrieval Cost, Invalidation, Replacement Policy, Optimal Replacement Policy, Caching Algorithms, Least Frequently Used (LFU), Least Recently Used (LRU), Least Recently Used 2(LRU2), Two Queues, Adaptive Replacement Cache (ACR), Most Recently Used (MRU), First in First out (FIFO), Distributed caching, Measuring Cache.
5 0.79369694 436 high scalability-2008-11-02-Strategy: How to Manage Sessions Using Memcached
Introduction: Dormando shows an enlightened middle way for storing sessions in cache and the database. Sessions are a perfect cache candidate because they are transient, smallish, and since they are usually accessed on every page access removing all that load from the database is a good thing. But as Dormando points out session caches have problems. If you remove expiration times from the cache and you run out of memory then no more logins. If a cache server fails or needs to be upgrade then you just logged out a bunch of potentially angry users. The middle ground Dormando proposes is using both the cache and the database: Reads : read from the cache first, then the database. Typical cache logic. Writes : write to memcached every time, write to the database every N seconds (assuming the data has changed). There's a small chance of data loss, but you've still greatly reduced the database load while providing reliability. Nice solution.
6 0.78967011 836 high scalability-2010-06-04-Strategy: Cache Larger Chunks - Cache Hit Rate is a Bad Indicator
7 0.76888537 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier
8 0.73779994 174 high scalability-2007-12-05-Product: Tugela Cache
9 0.73531979 467 high scalability-2008-12-16-[ANN] New Open Source Cache System
10 0.73431957 359 high scalability-2008-07-29-Ehcache - A Java Distributed Cache
12 0.7306354 248 high scalability-2008-02-13-What's your scalability plan?
13 0.72408766 247 high scalability-2008-02-12-We want to cache a lot :) How do we go about it ?
14 0.71213406 703 high scalability-2009-09-12-How Google Taught Me to Cache and Cash-In
15 0.71159941 662 high scalability-2009-07-27-Handle 700 Percent More Requests Using Squid and APC Cache
16 0.70894659 367 high scalability-2008-08-17-Strategy: Drop Memcached, Add More MySQL Servers
17 0.70096707 1633 high scalability-2014-04-16-Six Lessons Learned the Hard Way About Scaling a Million User System
18 0.70008594 1321 high scalability-2012-09-12-Using Varnish for Paywalls: Moving Logic to the Edge
19 0.69875127 1620 high scalability-2014-03-27-Strategy: Cache Stored Procedure Results
20 0.6942718 602 high scalability-2009-05-17-Scaling Django Web Apps by Mike Malone
topicId topicWeight
[(1, 0.045), (2, 0.835), (79, 0.023)]
simIndex simValue blogId blogTitle
1 0.99960428 223 high scalability-2008-01-25-Google: Introduction to Distributed System Design
Introduction: Update: Google added videos on Cluster Computing and MapReduce . There are five lectures: Introduction, MapReduce, Distributed File Systems, Clustering Algorithms, and Graph Algorithms . Advanced website design depends on deep distributed system design knowledge. Where do you get this knowledge? Try Google. They have a a whole Code for Educators program with tutorials and lectures on AJAX programming, distributed systems, and web security. Looks pretty nice.
2 0.99888468 436 high scalability-2008-11-02-Strategy: How to Manage Sessions Using Memcached
Introduction: Dormando shows an enlightened middle way for storing sessions in cache and the database. Sessions are a perfect cache candidate because they are transient, smallish, and since they are usually accessed on every page access removing all that load from the database is a good thing. But as Dormando points out session caches have problems. If you remove expiration times from the cache and you run out of memory then no more logins. If a cache server fails or needs to be upgrade then you just logged out a bunch of potentially angry users. The middle ground Dormando proposes is using both the cache and the database: Reads : read from the cache first, then the database. Typical cache logic. Writes : write to memcached every time, write to the database every N seconds (assuming the data has changed). There's a small chance of data loss, but you've still greatly reduced the database load while providing reliability. Nice solution.
Introduction: This is an interesting tidbit from near the end of the Packet Pushers podcast Show 15 – Saving the Web With Dinky Putt Putt Firewalls . The conversation was about how SSL connections need to terminate before they can be processed by a WAF ( Web Application Firewall ), which inspects HTTP for security problems like SQL injection and cross-site scripting exploits. Much was made that if programmers did their job better these appliances wouldn't be necessary, but I digress. To terminate SSL most shops run SSL connections into Intel based Linux boxes running Apache. This setup is convenient for developers, but it's not optimized for SSL, so it's slow and costly. Much of the capacity of these servers are unnecessarily consumed processing SSL. Load balancers on the other hand have crypto cards that terminate SSL very efficiently in hardware. Efficiently enough that if you are willing to get rid of the general purpose Linux boxes and use your big iron load balancers, your server count c
4 0.9987945 836 high scalability-2010-06-04-Strategy: Cache Larger Chunks - Cache Hit Rate is a Bad Indicator
Introduction: Isn't the secret to fast, scalable websites to cache everything ? Caching, if not the secret sauce of many a website, is it at least a popular condiment. But not so fast says Peter Zaitsev in Beyond great cache hit ratio . The point Peter makes is that we read about websites like Amazon and Facebook that can literally make hundreds of calls to satisfy a user request. Even if you have an awesome cache hit ratio, pages can still be slow because making and processing all those requests takes time. The solution is to remove requests all together . You do this by caching larger blocks so you have to make fewer requests. The post has a lot of good advice worth reading: 1) Make non cacheable blocks as small as possible, 2) Maximize amount of uses of the cache item, 3) Control invalidation, 4) Multi-Get.
same-blog 5 0.99878538 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
6 0.99816835 56 high scalability-2007-08-03-Running Hadoop MapReduce on Amazon EC2 and Amazon S3
7 0.99816835 565 high scalability-2009-04-13-Benchmark for keeping data in browser in AJAX projects
8 0.99387318 594 high scalability-2009-05-08-Eight Best Practices for Building Scalable Systems
9 0.99361497 455 high scalability-2008-12-01-MySQL Database Scale-out and Replication for High Growth Businesses
10 0.98782372 1155 high scalability-2011-12-12-Netflix: Developing, Deploying, and Supporting Software According to the Way of the Cloud
11 0.98763222 205 high scalability-2008-01-10-Letting Clients Know What's Changed: Push Me or Pull Me?
12 0.97595614 50 high scalability-2007-07-31-BerkeleyDB & other distributed high performance key-value databases
13 0.97545862 967 high scalability-2011-01-03-Stuff The Internet Says On Scalability For January 3, 2010
14 0.97105759 723 high scalability-2009-10-16-Paper: Scaling Online Social Networks without Pains
15 0.96734399 844 high scalability-2010-06-18-Paper: The Declarative Imperative: Experiences and Conjectures in Distributed Logic
16 0.96674722 417 high scalability-2008-10-15-Outside.in Scales Up with Engine Yard and moving from PHP to Ruby on Rails
17 0.96518487 1190 high scalability-2012-02-10-Stuff The Internet Says On Scalability For February 10, 2012
18 0.96278328 1199 high scalability-2012-02-27-Zen and the Art of Scaling - A Koan and Epigram Approach
19 0.96201032 1591 high scalability-2014-02-05-Little’s Law, Scalability and Fault Tolerance: The OS is your bottleneck. What you can do?
20 0.95855999 1006 high scalability-2011-03-17-Are long VM instance spin-up times in the cloud costing you money?