high_scalability high_scalability-2008 high_scalability-2008-431 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: What's cool about starting a new project is you finally have a chance to do it right. You of course eventually mess everything up in your own way, but for that one moment the world has a perfect order, a rightness that feels satisfying and good. Arne Claassen, the CTO of notify.me, a brand new real time notification delivery service, is in this honeymoon period now. Arne has been gracious enough to share with us his philosophy of how to build a notification service. I think you'll find it fascinating because Arne goes into a lot of useful detail about how his system works. His main design philosophy is to minimize the bottlenecks that form around synchronous access, that is when some resource is requested and the requestor ties up more resources, waiting for a response. If the requested resource can’t be delivered in a timely manner, more and more requests pile up until the server can’t accept any new ones. Nobody gets what they want and you have an outage. Breaking synchronous op
sentIndex sentText sentNum sentScore
1 Agent avatars are the delivery gateways that provide presence information of our users into the bus and deliver messages to our users. [sent-98, score-0.742]
2 This avatar pulls new messages from a store and forward queue and notifies its subscribers of the new message. [sent-101, score-0.832]
3 It is responsible for receiving new notifications from ingestion avatars, deciding on the routing and pushing messages to the appropriate delivery agent as that agent declares the ability to execute that delivery. [sent-104, score-0.823]
4 We have three different xmpp clusters which take advantage of federation for cross-chatter: user, agent and the avatar bus. [sent-130, score-0.946]
5 This account also serves as the user our desktop app signs in as and that will be the authentication for our API for third party message ingestion and distribution Agents The daemons connecting to this cluster serve as communication bridges between our internal Avatar bus and outside clients. [sent-132, score-0.683]
6 I mentioned earlier that Agents are avatars as well, however they are a little special in that they do not have a user on the Avatar bus but talk to other avatars through cross server federation. [sent-137, score-0.865]
7 We currently are also building agents for the Oscar and MSN networks that will sit directly on the avatar bus since their native transport is not federated. [sent-138, score-0.85]
8 It's a daemon (where a single physical daemon process can host many avatar daemons) that is the authority for some external entity's data. [sent-143, score-0.763]
9 me has an avatar that monitors agents for status changes, receives messages in care of that user and is responsible for routing those messages to the appropriate delivery channel. [sent-147, score-1.21]
10 This means that every avatar is the single authority for all data about that user and is responsible to persisting the data. [sent-148, score-0.878]
11 Since only the avatar can write its own data, it does not need to check the DB but can treat its memory and disk cache as authoritative and SDB is used primarily for writes. [sent-151, score-0.606]
12 Reads are needed only in the case of a node failure to bring up the avatar on another node. [sent-152, score-0.556]
13 Ingestors are made up of a number of daemons, generally running on polling loops against external sources, queueing new data into our store-and-forward queues, where the appropriate ingestor avatar picks up new messages and distributes them to its subscribers. [sent-154, score-0.753]
14 In the ingestor avatar scenario, it is the authority on subscription and routing data. [sent-155, score-0.728]
15 As new rss items arrive, the rss ingestor multiplexes items to all user avatars that subscribe to that feed. [sent-158, score-0.831]
16 In general that means that the user avatar is subscribed to the user's Xmpp presence via the users' agent. [sent-160, score-0.832]
17 Until the user is in the proper state for accepting messages, the user avatar queues the rss items. [sent-161, score-0.53]
18 Once the user is ready to receive the notification, the presence change is propagated from the agent into the internal bus and the user avatar then sends the rss items to agent, which in turn delivers it to the user. [sent-162, score-1.349]
19 We're only starting to use the avatar system as our backbone, so it's still a bit fragile and we're still doing load testing on ejabberd to determine at what point we run into limiting factors. [sent-169, score-0.649]
20 Since our messaging is primarily point-to-point, we anticipate that we can split our user base into avatar silos, each hosted on a dedicated avatar subdomain cluster, reducing message and connection load. [sent-171, score-1.298]
wordName wordTfidf (topN-words)
[('avatar', 0.556), ('xmpp', 0.277), ('avatars', 0.247), ('bus', 0.203), ('user', 0.168), ('notification', 0.145), ('rss', 0.141), ('messages', 0.138), ('ingestion', 0.12), ('agent', 0.113), ('message', 0.112), ('delivery', 0.097), ('ejabberd', 0.093), ('agents', 0.091), ('arne', 0.089), ('ingestor', 0.089), ('ingestors', 0.089), ('im', 0.088), ('notifications', 0.087), ('routing', 0.083), ('daemons', 0.08), ('authority', 0.077), ('responsible', 0.077), ('messaging', 0.077), ('daemon', 0.065), ('allowing', 0.064), ('appropriate', 0.063), ('queues', 0.059), ('claassen', 0.059), ('stanzas', 0.059), ('subdomain', 0.059), ('central', 0.059), ('presence', 0.057), ('silos', 0.056), ('users', 0.055), ('mnesia', 0.054), ('state', 0.053), ('feed', 0.052), ('rpc', 0.051), ('via', 0.051), ('primarily', 0.05), ('queue', 0.048), ('sources', 0.048), ('chatter', 0.048), ('destinations', 0.046), ('msn', 0.046), ('able', 0.046), ('new', 0.045), ('persists', 0.045), ('passing', 0.044)]
simIndex simValue blogId blogTitle
same-blog 1 1.0000004 431 high scalability-2008-10-27-Notify.me Architecture - Synchronicity Kills
Introduction: What's cool about starting a new project is you finally have a chance to do it right. You of course eventually mess everything up in your own way, but for that one moment the world has a perfect order, a rightness that feels satisfying and good. Arne Claassen, the CTO of notify.me, a brand new real time notification delivery service, is in this honeymoon period now. Arne has been gracious enough to share with us his philosophy of how to build a notification service. I think you'll find it fascinating because Arne goes into a lot of useful detail about how his system works. His main design philosophy is to minimize the bottlenecks that form around synchronous access, that is when some resource is requested and the requestor ties up more resources, waiting for a response. If the requested resource can’t be delivered in a timely manner, more and more requests pile up until the server can’t accept any new ones. Nobody gets what they want and you have an outage. Breaking synchronous op
2 0.19715194 318 high scalability-2008-05-14-New Facebook Chat Feature Scales to 70 Million Users Using Erlang
Introduction: Update : Erlang at Facebook by Eugene Letuchy. How Facebook uses Erlang to implement Chat, AIM Presence, and Chat Jabber support. I've done some XMPP development so when I read Facebook was making a Jabber chat client I was really curious how they would make it work. While core XMPP is straightforward, a number of protocol extensions like discovery, forms, chat states, pubsub, multi user chat, and privacy lists really up the implementation complexity. Some real engineering challenges were involved to make this puppy scale and perform. It's not clear what extensions they've implemented, but a blog entry by Facebook's Eugene Letuchy hits some of the architectural challenges they faced and how they overcame them. A web based Jabber client poses a few problems because XMPP, like most IM protocols, is an asynchronous event driven system that pretty much assumes you have a full time open connection. After logging in the server sends a client roster information and presence info
3 0.17208488 1573 high scalability-2014-01-06-How HipChat Stores and Indexes Billions of Messages Using ElasticSearch and Redis
Introduction: This article is from an interview with Zuhaib Siddique , a production engineer at HipChat , makers of group chat and IM for teams. HipChat started in an unusual space, one you might not think would have much promise, enterprise group messaging, but as we are learning there is gold in them there enterprise hills . Which is why Atlassian, makers of well thought of tools like JIRA and Confluence, acquired HipChat in 2012 . And in a tale not often heard, the resources and connections of a larger parent have actually helped HipChat enter an exponential growth cycle . Having reached the 1.2 billion message storage mark they are now doubling the number of messages sent, stored, and indexed every few months. That kind of growth puts a lot of pressure on a once adequate infrastructure. HipChat exhibited a common scaling pattern. Start simple, experience traffic spikes, and then think what do we do now? Using bigger computers is usually the first and bes
4 0.15491921 1312 high scalability-2012-08-27-Zoosk - The Engineering behind Real Time Communications
Introduction: This is a guest post by Peter Offringa, VP of engineering at Zoosk . Zoosk is a 50 million member romantic social network. Our members get the most rewarding experience from Zoosk when they can interact in real-time. After all, a future relationship is potentially at the other end of every connection a user makes. The excitement and richness of this situation can only be fully realized in real-time. The suite of Zoosk services facilitating these interactions are referred to by the general description of real-time communications (RTC). These communications are delivered using the XMPP protocol, which also powers other popular instant messaging products. Zoosk members experience real-time communications within three distinct interactions: Presence . When a member is actively connected to the Zoosk RTC infrastructure, their public status appears as ‘available’. If they are idle for a period of time, their state transitions to ‘away’. Their presence automatically changes to
5 0.15376438 1501 high scalability-2013-08-13-In Memoriam: Lavabit Architecture - Creating a Scalable Email Service
Introduction: With Lavabit shutting down under murky circumstances , it seems fitting to repost an old (2009), yet still very good post by Ladar Levison on Lavabit's architecture. I don't know how much of this information is still current, but it should give you a general idea what Lavabit was all about. Getting to Know You What is the name of your system and where can we find out more about it? Note: these links are no longer valid... Lavabit http://lavabit.com http://lavabit.com/network.html http://lavabit.com/about.html What is your system for? Lavabit is a mid-sized email service provider. We currently have about 140,000 registered users with more than 260,000 email addresses. While most of our accounts belong to individual users, we also provide corporate email services to approximately 70 companies. Why did you decide to build this system? We built the system to compete against the other large free email providers, with an emphasis on serving the privacy c
6 0.14404686 234 high scalability-2008-01-30-The AOL XMPP scalability challenge
8 0.1305254 639 high scalability-2009-06-27-Scaling Twitter: Making Twitter 10000 Percent Faster
9 0.12925628 21 high scalability-2007-07-23-GoogleTalk Architecture
10 0.12891181 1578 high scalability-2014-01-14-Ask HS: Design and Implementation of scalable services?
11 0.12747869 1240 high scalability-2012-05-07-Startups are Creating a New System of the World for IT
12 0.12557931 1042 high scalability-2011-05-17-Facebook: An Example Canonical Architecture for Scaling Billions of Messages
14 0.1232553 353 high scalability-2008-07-20-Strategy: Front S3 with a Caching Proxy
15 0.12191104 1602 high scalability-2014-02-26-The WhatsApp Architecture Facebook Bought For $19 Billion
16 0.12054137 1421 high scalability-2013-03-11-Low Level Scalability Solutions - The Conditioning Collection
17 0.12001482 1 high scalability-2007-07-06-Start Here
18 0.1199807 1373 high scalability-2012-12-17-11 Uses For the Humble Presents Queue, er, Message Queue
19 0.11730023 808 high scalability-2010-04-12-Poppen.de Architecture
20 0.11551046 821 high scalability-2010-05-03-MocoSpace Architecture - 3 Billion Mobile Page Views a Month
topicId topicWeight
[(0, 0.212), (1, 0.084), (2, -0.015), (3, -0.063), (4, 0.006), (5, -0.038), (6, 0.031), (7, 0.029), (8, -0.026), (9, -0.001), (10, 0.032), (11, 0.137), (12, 0.003), (13, -0.049), (14, 0.011), (15, 0.029), (16, 0.008), (17, 0.0), (18, 0.034), (19, -0.025), (20, -0.011), (21, -0.05), (22, 0.011), (23, 0.019), (24, 0.014), (25, -0.011), (26, 0.036), (27, 0.02), (28, -0.01), (29, 0.002), (30, 0.031), (31, -0.033), (32, -0.015), (33, -0.028), (34, 0.041), (35, -0.03), (36, 0.014), (37, -0.021), (38, -0.015), (39, -0.005), (40, 0.068), (41, -0.017), (42, 0.034), (43, 0.033), (44, -0.043), (45, -0.006), (46, -0.081), (47, 0.014), (48, -0.085), (49, -0.006)]
simIndex simValue blogId blogTitle
same-blog 1 0.95743573 431 high scalability-2008-10-27-Notify.me Architecture - Synchronicity Kills
Introduction: What's cool about starting a new project is you finally have a chance to do it right. You of course eventually mess everything up in your own way, but for that one moment the world has a perfect order, a rightness that feels satisfying and good. Arne Claassen, the CTO of notify.me, a brand new real time notification delivery service, is in this honeymoon period now. Arne has been gracious enough to share with us his philosophy of how to build a notification service. I think you'll find it fascinating because Arne goes into a lot of useful detail about how his system works. His main design philosophy is to minimize the bottlenecks that form around synchronous access, that is when some resource is requested and the requestor ties up more resources, waiting for a response. If the requested resource can’t be delivered in a timely manner, more and more requests pile up until the server can’t accept any new ones. Nobody gets what they want and you have an outage. Breaking synchronous op
2 0.83336657 1312 high scalability-2012-08-27-Zoosk - The Engineering behind Real Time Communications
Introduction: This is a guest post by Peter Offringa, VP of engineering at Zoosk . Zoosk is a 50 million member romantic social network. Our members get the most rewarding experience from Zoosk when they can interact in real-time. After all, a future relationship is potentially at the other end of every connection a user makes. The excitement and richness of this situation can only be fully realized in real-time. The suite of Zoosk services facilitating these interactions are referred to by the general description of real-time communications (RTC). These communications are delivered using the XMPP protocol, which also powers other popular instant messaging products. Zoosk members experience real-time communications within three distinct interactions: Presence . When a member is actively connected to the Zoosk RTC infrastructure, their public status appears as ‘available’. If they are idle for a period of time, their state transitions to ‘away’. Their presence automatically changes to
3 0.79566687 406 high scalability-2008-10-08-Strategy: Flickr - Do the Essential Work Up-front and Queue the Rest
Introduction: This strategy is stated perfectly by Flickr's Myles Grant: The Flickr engineering team is obsessed with making pages load as quickly as possible. To that end, we’re refactoring large amounts of our code to do only the essential work up front, and rely on our queuing system to do the rest. Flickr uses a queuing system to process 11 million tasks a day. Leslie Michael Orchard also does a great job explaining the queuing meme in his excellent post Queue everything and delight everyone . Asynchronous work queues are how you scalably solve problems that are too big to handle in real-time. The process: Identify the minimum feedback the client (UI, API) needs to know an operation succeeded . It's enough, for example, to update a client's view when a posting a message to a microblogging service. The client probably isn't aware of all the other steps that happen when a message is added and doesn't really care when they happen as long as the obvious cases happen in an appropariate
Introduction: This article is from an interview with Zuhaib Siddique , a production engineer at HipChat , makers of group chat and IM for teams. HipChat started in an unusual space, one you might not think would have much promise, enterprise group messaging, but as we are learning there is gold in them there enterprise hills . Which is why Atlassian, makers of well thought of tools like JIRA and Confluence, acquired HipChat in 2012 . And in a tale not often heard, the resources and connections of a larger parent have actually helped HipChat enter an exponential growth cycle . Having reached the 1.2 billion message storage mark they are now doubling the number of messages sent, stored, and indexed every few months. That kind of growth puts a lot of pressure on a once adequate infrastructure. HipChat exhibited a common scaling pattern. Start simple, experience traffic spikes, and then think what do we do now? Using bigger computers is usually the first and bes
5 0.78094447 1373 high scalability-2012-12-17-11 Uses For the Humble Presents Queue, er, Message Queue
Introduction: It's a little known fact that Santa Clause was an early queue innovator. Faced with the problem of delivering a planet full of presents in one night, Santa, in his hacker's workshop, created a Present Distribution System using thousands of region based priority present queues for continuous delivery by the Rudolphs. Rudolphs? You didn't think there was only one Rudolph did you? Presents are delivered in parallel by a cluster of sleighs, each with redundant reindeer in a master-master configuration. Each Rudolph is a cluster leader and they coordinate work using an early and more magical version of the ZooKeeper protocol. Programmers have followed Santa's lead and you can find a message queue in nearly every major architecture profile on HighScalability . Historically they may have been introduced after a first generation architecture needed to scale up from their two tier system into something a little more capable (asynchronicity, work dispatch, load buffering, database offloadin
6 0.77811658 205 high scalability-2008-01-10-Letting Clients Know What's Changed: Push Me or Pull Me?
8 0.76167661 1577 high scalability-2014-01-13-NYTimes Architecture: No Head, No Master, No Single Point of Failure
10 0.7581256 478 high scalability-2008-12-29-Paper: Spamalytics: An Empirical Analysisof Spam Marketing Conversion
11 0.75294918 985 high scalability-2011-02-08-Mollom Architecture - Killing Over 373 Million Spams at 100 Requests Per Second
12 0.75282937 1421 high scalability-2013-03-11-Low Level Scalability Solutions - The Conditioning Collection
13 0.75256062 1609 high scalability-2014-03-11-Building a Social Music Service Using AWS, Scala, Akka, Play, MongoDB, and Elasticsearch
14 0.75066209 350 high scalability-2008-07-15-ZooKeeper - A Reliable, Scalable Distributed Coordination System
15 0.7494387 343 high scalability-2008-06-09-Apple's iPhone to Use a Centralized Push Based Notification Architecture
17 0.74250513 1602 high scalability-2014-02-26-The WhatsApp Architecture Facebook Bought For $19 Billion
18 0.7419247 21 high scalability-2007-07-23-GoogleTalk Architecture
19 0.7395249 318 high scalability-2008-05-14-New Facebook Chat Feature Scales to 70 Million Users Using Erlang
20 0.73530471 1277 high scalability-2012-07-05-10 Golden Principles For Building Successful Mobile-Web Applications
topicId topicWeight
[(1, 0.151), (2, 0.212), (5, 0.017), (10, 0.048), (16, 0.013), (19, 0.132), (30, 0.03), (40, 0.027), (47, 0.016), (61, 0.079), (77, 0.034), (79, 0.088), (85, 0.031), (91, 0.01), (94, 0.024)]
simIndex simValue blogId blogTitle
same-blog 1 0.94905561 431 high scalability-2008-10-27-Notify.me Architecture - Synchronicity Kills
Introduction: What's cool about starting a new project is you finally have a chance to do it right. You of course eventually mess everything up in your own way, but for that one moment the world has a perfect order, a rightness that feels satisfying and good. Arne Claassen, the CTO of notify.me, a brand new real time notification delivery service, is in this honeymoon period now. Arne has been gracious enough to share with us his philosophy of how to build a notification service. I think you'll find it fascinating because Arne goes into a lot of useful detail about how his system works. His main design philosophy is to minimize the bottlenecks that form around synchronous access, that is when some resource is requested and the requestor ties up more resources, waiting for a response. If the requested resource can’t be delivered in a timely manner, more and more requests pile up until the server can’t accept any new ones. Nobody gets what they want and you have an outage. Breaking synchronous op
2 0.94527501 29 high scalability-2007-07-25-Product: lighttpd
Introduction: Lighttpd (pronounced "lighty") is a web server which is designed to be secure, fast, standards-compliant, and flexible while being optimized for speed-critical environments. Its low memory footprint (compared to other web servers), light CPU load and its speed goals make lighttpd suitable for servers that are suffering load problems, or for serving static media separately from dynamic content. lighttpd is free software / open source, and is distributed under the BSD license. lighttpd runs on GNU/Linux and other Unix-like operating systems and Microsoft Windows. Load-balancing FastCGI, SCGI and HTTP-proxy support chroot support select()-/poll()-based web server Support for more efficient event notification schemes like kqueue and epoll Conditional rewrites (mod_rewrite) SSL and TLS support, via openSSL. Authentication against an LDAP server rrdtool statistics Rule-based downloading with possibility of a script handling only authentication Server-side includes supp
Introduction: Algorithms are moving out of the Platonic realm and are becoming dynamic first class players in real life. We've seen corporations become people. Algorithms will likely also follow that path to agency. Kevin Slavin in his intriguing TED talk: How Algorithms Shape Our World , gives many and varied examples of how algorithms have penetrated RL. One of his most interesting examples is from a highly technical paper on Relativistic statistical arbitrage , which says to make money on markets you have to be where the people are, the red dots (on the diagram below), which means you have to put servers where the blue dots are, many of which are in the ocean. Here's the diagram from the paper: Mr. Slavin neatly sums this up by saying: And it's not the money that's so interesting actually. It's what the money motivates, that we're actually terraforming the Earth itself with this kind of algorithmic efficiency . And in that light, you go back and you look at Michael Najjar's ph
4 0.92869163 733 high scalability-2009-10-29-Paper: No Relation: The Mixed Blessings of Non-Relational Databases
Introduction: This excellent survey of the field was written by Ian Thomas Varley as part of his Master of Science in Engineering program. The aim of this paper is to explore the conceptual design space of non-relational databases as compared to traditional relational databases. It is clear that the design needs of the two paradigms are different, but how fundamental are the differences, and what strategies can we use to transition our conceptual designs from one to the other? There are a few things to like about this paper. A running a example is used to show the different ways to model data depending on which type of solution you are targeting, especially covering how many-to-many relationships are modeled, data integrity, and how to support optional attributes. There's also a brief survey of some of the major systems. The most interesting section of the report is where it tackles the problem of design for non-relational systems. The approach has two different phases: design q
5 0.91872865 1151 high scalability-2011-12-05-Stuff The Internet Says On Scalability For December 5, 2011
Introduction: It's HighScalability Time! Quotable quotes: @jaykreps : Was wondering, How can I turn my boring, cachable, read-only traffic into random writes on mongodb? And lo! link @marshallk : Google runs 100-200 experiments every day on UI, algorithm & product @styggiti : The problem with companies like IBM and Oracle baking NoSQL "scalability" into their products isn't the tech, it's the $$ licensing. Blazing fast node.js: 10 performance tips from LinkedIn Mobile . You may have thought that node.js made just everything magically fast, but Shravya Garlapati has some great strategies for going even faster: Avoid synchronous code; Turn off socket pooling; Don't use Node.js for static assets; Render on the client-side; Use gzip; Go parallel; Go session-free; Use binary modules; Use standard V8 JavaScript instead of client-side libraries; Keep your code small and light. Nice thread in NoSQL Databases on HBase and Consistency in CAP . The short summary of the a
7 0.90324044 1064 high scalability-2011-06-20-35+ Use Cases for Choosing Your Next NoSQL Database
8 0.90254712 1600 high scalability-2014-02-21-Stuff The Internet Says On Scalability For February 21st, 2014
9 0.90208787 1537 high scalability-2013-10-25-Stuff The Internet Says On Scalability For October 25th, 2013
10 0.90127319 106 high scalability-2007-10-02-Secrets to Fotolog's Scaling Success
11 0.90026319 1372 high scalability-2012-12-14-Stuff The Internet Says On Scalability For December 14, 2012
12 0.9002108 1302 high scalability-2012-08-10-Stuff The Internet Says On Scalability For August 10, 2012
13 0.90006834 1008 high scalability-2011-03-22-Facebook's New Realtime Analytics System: HBase to Process 20 Billion Events Per Day
14 0.89946377 1508 high scalability-2013-08-28-Sean Hull's 20 Biggest Bottlenecks that Reduce and Slow Down Scalability
15 0.89933413 998 high scalability-2011-03-03-Stack Overflow Architecture Update - Now at 95 Million Page Views a Month
16 0.89930224 1499 high scalability-2013-08-09-Stuff The Internet Says On Scalability For August 9, 2013
17 0.89929694 1171 high scalability-2012-01-09-The Etsy Saga: From Silos to Happy to Billions of Pageviews a Month
19 0.89912039 808 high scalability-2010-04-12-Poppen.de Architecture
20 0.89869034 160 high scalability-2007-11-19-Tailrank Architecture - Learn How to Track Memes Across the Entire Blogosphere