high_scalability high_scalability-2008 high_scalability-2008-436 knowledge-graph by maker-knowledge-mining
Source: html
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.
sentIndex sentText sentNum sentScore
1 Dormando shows an enlightened middle way for storing sessions in cache and the database. [sent-1, score-1.136]
2 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. [sent-2, score-1.342]
3 But as Dormando points out session caches have problems. [sent-3, score-0.265]
4 If you remove expiration times from the cache and you run out of memory then no more logins. [sent-4, score-0.72]
5 If a cache server fails or needs to be upgrade then you just logged out a bunch of potentially angry users. [sent-5, score-1.165]
6 The middle ground Dormando proposes is using both the cache and the database: Reads : read from the cache first, then the database. [sent-6, score-1.259]
7 Writes : write to memcached every time, write to the database every N seconds (assuming the data has changed). [sent-8, score-0.695]
8 There's a small chance of data loss, but you've still greatly reduced the database load while providing reliability. [sent-9, score-0.648]
wordName wordTfidf (topN-words)
[('dormando', 0.432), ('cache', 0.368), ('middle', 0.242), ('enlightened', 0.23), ('smallish', 0.23), ('sessions', 0.215), ('angry', 0.179), ('proposes', 0.172), ('expiration', 0.157), ('transient', 0.153), ('logged', 0.14), ('assuming', 0.135), ('greatly', 0.127), ('removing', 0.125), ('candidate', 0.123), ('fails', 0.115), ('loss', 0.112), ('database', 0.112), ('every', 0.112), ('bunch', 0.109), ('potentially', 0.109), ('ground', 0.109), ('reduced', 0.108), ('accessed', 0.103), ('caches', 0.103), ('write', 0.102), ('remove', 0.098), ('chance', 0.097), ('changed', 0.094), ('seconds', 0.089), ('upgrade', 0.087), ('session', 0.084), ('storing', 0.081), ('providing', 0.08), ('typical', 0.08), ('points', 0.078), ('usually', 0.077), ('reads', 0.076), ('perfect', 0.075), ('load', 0.075), ('nice', 0.073), ('memcached', 0.066), ('since', 0.062), ('page', 0.061), ('needs', 0.058), ('times', 0.052), ('solution', 0.051), ('access', 0.049), ('small', 0.049), ('memory', 0.045)]
simIndex simValue blogId blogTitle
same-blog 1 1.0 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.
2 0.23321685 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.16213189 662 high scalability-2009-07-27-Handle 700 Percent More Requests Using Squid and APC Cache
Introduction: This post on www.ilovebonnie.net documents some impressive system performance improvements by the addition of Squid Cache (a caching proxy) and APC Cache (opcode cache for PHP). Apache is able to deliver roughly 700% more requests per second with Squid when serving 1KB and 100KB images. Server load is reduced using Squid because the server does not have to create a bunch of Apache processes to handle the requests. APC Cache took a system that could barely handle 10-20 requests per second to handling 50-60 requests per second. A 400% increase. APC allowed the load times to remain under 5 seconds even with 200 concurrent threads slamming on the server. These two caches are easy to setup and install and allow you to get a lot more performance out of them. The post has an in-depth discussion and a number of supporting charts. The primary point is how simple it can be to improve performance and scalability by adding caching.
4 0.15428048 467 high scalability-2008-12-16-[ANN] New Open Source Cache System
Introduction: The SHOP.COM Cache System is now available at http://code.google.com/p/sccache/ The SHOP.COM Cache System is an object cache system that... * is an in-process cache and external, shared Cache * is horizontally scalable * stores cached objects to disk * supports associative keys * is non-transactional * can have any size key and any size data * does auto-GC based on TTL * is container and platform neutral It was built in-house at SHOP.COM (by me) and has powered our website for years. We are open-sourcing it in the hope that it will be useful to others and to get some help in its maintenance. This is our first open source attempt and we'd appreciate any help and comments.
5 0.15412895 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
6 0.14447221 911 high scalability-2010-09-30-More Troubles with Caching
7 0.14040482 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier
8 0.13195775 367 high scalability-2008-08-17-Strategy: Drop Memcached, Add More MySQL Servers
9 0.13084863 174 high scalability-2007-12-05-Product: Tugela Cache
10 0.12949099 495 high scalability-2009-01-17-Intro to Caching,Caching algorithms and caching frameworks part 1
12 0.11952747 1633 high scalability-2014-04-16-Six Lessons Learned the Hard Way About Scaling a Million User System
13 0.11781562 703 high scalability-2009-09-12-How Google Taught Me to Cache and Cash-In
14 0.11639103 1126 high scalability-2011-09-27-Use Instance Caches to Save Money: Latency == $$$
15 0.11547183 373 high scalability-2008-08-29-Product: ScaleOut StateServer is Memcached on Steroids
16 0.10673033 248 high scalability-2008-02-13-What's your scalability plan?
17 0.10567173 910 high scalability-2010-09-30-Facebook and Site Failures Caused by Complex, Weakly Interacting, Layered Systems
18 0.10500754 577 high scalability-2009-04-22-Gear6 Web cache - the hardware solution for working with Memcache
19 0.10114813 316 high scalability-2008-05-05-Put the web server on a diet and increase scalability
20 0.097986668 927 high scalability-2010-10-26-Marrying memcached and NoSQL
topicId topicWeight
[(0, 0.112), (1, 0.075), (2, -0.072), (3, -0.13), (4, 0.007), (5, 0.08), (6, 0.014), (7, -0.023), (8, -0.079), (9, -0.04), (10, -0.005), (11, -0.078), (12, -0.009), (13, 0.118), (14, -0.096), (15, -0.047), (16, -0.057), (17, -0.024), (18, 0.043), (19, -0.018), (20, -0.082), (21, 0.083), (22, 0.104), (23, 0.06), (24, -0.038), (25, 0.003), (26, -0.004), (27, 0.095), (28, -0.078), (29, -0.016), (30, -0.053), (31, 0.025), (32, -0.036), (33, -0.037), (34, -0.046), (35, 0.065), (36, 0.015), (37, 0.025), (38, 0.071), (39, 0.004), (40, 0.028), (41, 0.02), (42, -0.07), (43, -0.009), (44, 0.002), (45, 0.019), (46, -0.0), (47, 0.041), (48, 0.01), (49, -0.041)]
simIndex simValue blogId blogTitle
same-blog 1 0.98535341 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.
2 0.8825891 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.
3 0.86533266 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier
Introduction: In a paper delivered at HotCloud '12 by a group from CMU and Intel Labs, Saving Cash by Using Less Cache ( slides , pdf ), they show it may be possible to use less DRAM under low load conditions to save on operational costs. There are some issues with this idea, but in a give me more cache era, it could be an interesting source of cost savings for your product. Caching is used to: Reduce load on the database. Reduce latency. Problem: RAM in the cloud is quite expensive. A third of costs can come from the caching tier. Solution: Shrink your cache when the load is lower. Their work shows when the load drops below a certain point you can throw away 50% of your cache while still maintaining performance. A few popular items often account for most of your hits, implying can remove the cache for the long tail. Use two tiers of servers, the Retiring Group, which is the group of servers you want to get rid of. The Primary Group is the group of servers you
4 0.86205882 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
5 0.85966194 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
6 0.85656846 467 high scalability-2008-12-16-[ANN] New Open Source Cache System
7 0.82134557 174 high scalability-2007-12-05-Product: Tugela Cache
8 0.81887072 359 high scalability-2008-07-29-Ehcache - A Java Distributed Cache
9 0.7942521 911 high scalability-2010-09-30-More Troubles with Caching
10 0.79238778 836 high scalability-2010-06-04-Strategy: Cache Larger Chunks - Cache Hit Rate is a Bad Indicator
11 0.76586246 703 high scalability-2009-09-12-How Google Taught Me to Cache and Cash-In
12 0.76154828 662 high scalability-2009-07-27-Handle 700 Percent More Requests Using Squid and APC Cache
13 0.7471981 1620 high scalability-2014-03-27-Strategy: Cache Stored Procedure Results
14 0.73931575 149 high scalability-2007-11-12-Scaling Using Cache Farms and Read Pooling
15 0.73825967 247 high scalability-2008-02-12-We want to cache a lot :) How do we go about it ?
16 0.73146737 191 high scalability-2007-12-23-Synchronizing Memcached application
17 0.73103815 1633 high scalability-2014-04-16-Six Lessons Learned the Hard Way About Scaling a Million User System
18 0.72433579 908 high scalability-2010-09-28-6 Strategies for Scaling BBC iPlayer
19 0.7217226 367 high scalability-2008-08-17-Strategy: Drop Memcached, Add More MySQL Servers
topicId topicWeight
[(1, 0.017), (2, 0.848)]
simIndex simValue blogId blogTitle
1 0.99980271 56 high scalability-2007-08-03-Running Hadoop MapReduce on Amazon EC2 and Amazon S3
Introduction: Excellent article on using Hadoop in Amazon's services environment to solve real problems for very little money. It's excellent because it shows how the stack works together and it actually seems like something a real human could do.
2 0.99980271 565 high scalability-2009-04-13-Benchmark for keeping data in browser in AJAX projects
Introduction: Hi, We are using AJAX and see a lot of opportunity to keep session state on client browser with javascript objects. Is there any benchmark about how much data you can generally keep in javascript objects in browser? Thanks, Unmesh
same-blog 3 0.99975175 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.
4 0.99961442 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.
5 0.99719852 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.
6 0.99691445 878 high scalability-2010-08-12-Strategy: Terminate SSL Connections in Hardware and Reduce Server Count by 40%
7 0.9961434 911 high scalability-2010-09-30-More Troubles with Caching
8 0.98977816 594 high scalability-2009-05-08-Eight Best Practices for Building Scalable Systems
9 0.98967493 455 high scalability-2008-12-01-MySQL Database Scale-out and Replication for High Growth Businesses
10 0.9812572 205 high scalability-2008-01-10-Letting Clients Know What's Changed: Push Me or Pull Me?
11 0.98048186 1155 high scalability-2011-12-12-Netflix: Developing, Deploying, and Supporting Software According to the Way of the Cloud
12 0.96669292 967 high scalability-2011-01-03-Stuff The Internet Says On Scalability For January 3, 2010
13 0.96655715 50 high scalability-2007-07-31-BerkeleyDB & other distributed high performance key-value databases
14 0.96273154 723 high scalability-2009-10-16-Paper: Scaling Online Social Networks without Pains
15 0.95946306 417 high scalability-2008-10-15-Outside.in Scales Up with Engine Yard and moving from PHP to Ruby on Rails
16 0.9582575 844 high scalability-2010-06-18-Paper: The Declarative Imperative: Experiences and Conjectures in Distributed Logic
17 0.95413876 1190 high scalability-2012-02-10-Stuff The Internet Says On Scalability For February 10, 2012
18 0.95313799 1199 high scalability-2012-02-27-Zen and the Art of Scaling - A Koan and Epigram Approach
19 0.95171869 1591 high scalability-2014-02-05-Little’s Law, Scalability and Fault Tolerance: The OS is your bottleneck. What you can do?
20 0.94696766 1006 high scalability-2011-03-17-Are long VM instance spin-up times in the cloud costing you money?