<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://www.morling.dev/blog/kip-932-queues-for-kafka/"/>
	<rdf:li rdf:resource="https://softwaremill.com/mqperf/"/>
	<rdf:li rdf:resource="https://dublinairportwait.ie/"/>
	<rdf:li rdf:resource="http://richardstartin.uk/tuning-spark-back-pressure-by-simulation/"/>
	<rdf:li rdf:resource="https://segment.com/blog/introducing-centrifuge/"/>
	<rdf:li rdf:resource="https://atscaleconference.com/videos/cadence-microservice-architecture-beyond-requestreply/"/>
	<rdf:li rdf:resource="https://eng.uber.com/cherami/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-for-amazon-simple-queue-service-fifo-queues-with-exactly-once-delivery-deduplication/"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/hystrixoss/mCCXEwSXb9M/bi_XHKIDAAAJ"/>
	<rdf:li rdf:resource="https://github.com/conversant/disruptor"/>
	<rdf:li rdf:resource="https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you"/>
	<rdf:li rdf:resource="https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.h"/>
	<rdf:li rdf:resource="http://www.confluent.io/blog/apache-kafka-purgatory-hierarchical-timing-wheels"/>
	<rdf:li rdf:resource="https://blog.twitter.com/2015/flying-faster-with-twitter-heron"/>
	<rdf:li rdf:resource="http://www.developer-tech.com/news/2014/jun/10/why-loggly-loves-apache-kafka-how-unbreakable-infinitely-scalable-messaging-makes-log-management-better/"/>
	<rdf:li rdf:resource="http://tech.forter.com/comparing-message-queue-architectures-on-aws/"/>
	<rdf:li rdf:resource="https://github.com/sclasen/event-shuttle"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html"/>
	<rdf:li rdf:resource="https://projects.eclipse.org/proposals/moquette-mqtt"/>
	<rdf:li rdf:resource="http://psy-lob-saw.blogspot.ie/2014/04/notes-on-concurrent-ring-buffer-queue.html"/>
	<rdf:li rdf:resource="http://webcache.googleusercontent.com/search?q=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;oq=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;aqs=chrome..69i57j69i58.795j0j4&amp;sourceid=chrome&amp;espv=210&amp;es_sm=91&amp;ie=UTF-8"/>
	<rdf:li rdf:resource="http://reverbrain.com/grape/"/>
	<rdf:li rdf:resource="http://www.michael-noll.com/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster-on-a-single-node/#excursus-topics-partitions-and-replication-in-kafka"/>
	<rdf:li rdf:resource="https://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/"/>
	<rdf:li rdf:resource="http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics"/>
	<rdf:li rdf:resource="http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work"/>
	<rdf:li rdf:resource="https://github.com/nathanmarz/storm/wiki/Rationale"/>
	<rdf:li rdf:resource="http://devblog.bu.mp/how-we-use-redis-at-bump"/>
	<rdf:li rdf:resource="http://lists.openamq.org/pipermail/openamq-dev/2010-March/001598.html"/>
	<rdf:li rdf:resource="http://github.com/blog/542-introducing-resque"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://www.morling.dev/blog/kip-932-queues-for-kafka/">
    <title>KIP-932: Queues for Kafka</title>
    <dc:date>2025-03-06T11:27:32+00:00</dc:date>
    <link>https://www.morling.dev/blog/kip-932-queues-for-kafka/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
KIP-932 adds a long awaited capability to the Apache Kafka project: queue-like semantics, including the ability to acknowledge messages on a one-by-one basis. This positions Kafka for use cases such as job queuing, for which it hasn’t been a good fit historically. As multiple members of a share group can process the messages from a single topic partition, the partition count does not limit the degree of consumer parallelism any longer. The number of consumers in a group can quickly be increased and decreased as needed, without requiring to repartition the topic.

[....] Available as an early access feature as of the [unreleased] Kafka 4.0 release, Kafka queues are not recommended for production usage yet, and there are several limitations worth calling out: most importantly, the lack of DLQ support. More control over retry timing would be desirable, too. As such, I don’t think Kafka queues in their current form will make users of established queue solutions such as Artemis or RabbitMQ migrate to Kafka. It is a very useful addition to the Kafka feature set nevertheless, coming in handy for instance for teams already running Kafka and who look for a solution for simple queuing use cases, avoiding to stand up and operate a separate solution just for these. This story will become even more compelling if the feature gets built out and improved in future Kafka releases.
</blockquote>

https://jack-vanlightly.com/blog/2023/10/2/the-advantages-of-queues-on-logs is a fantastic article by Jack Vanlightly on the innards of a queue built atop a log, like Kafka's KIP-932.]]></description>
<dc:subject>kafka queueing queues architecture logs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b5eb93efb452/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://softwaremill.com/mqperf/">
    <title>Evaluating persistent, replicated message queues</title>
    <dc:date>2024-08-26T09:47:38+00:00</dc:date>
    <link>https://softwaremill.com/mqperf/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is exhaustive!

Kafka, Postgres, mongodb, Redis, Pulsar, SQS, EventStore, RocketMQ, RabbitMQ, ActiveMQ, and RedPanda all compared as backends for a persistent, replicated message queueing system.  SQS actually fares quite well
]]></description>
<dc:subject>activemq kafka rabbitmq messaging queueing message-queues sqs postgres storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d187c123119b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activemq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rabbitmq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:message-queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgres"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dublinairportwait.ie/">
    <title>Dublin Airport Security Wait Times</title>
    <dc:date>2022-05-21T10:56:37+00:00</dc:date>
    <link>https://dublinairportwait.ie/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[brilliant single-page website, scraping the "current wait time for security queues" data from Dublin Airport's own official site, and logging historical data in a graph.]]></description>
<dc:subject>security-queues queueing dublin-airport travel airports dublin ireland holidays</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9d7d46ddadd9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security-queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin-airport"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:travel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airports"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:holidays"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://richardstartin.uk/tuning-spark-back-pressure-by-simulation/">
    <title>Tuning Spark Back Pressure by Simulation</title>
    <dc:date>2018-11-15T10:40:53+00:00</dc:date>
    <link>http://richardstartin.uk/tuning-spark-back-pressure-by-simulation/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting, Spark uses a PID controller algorithm to manage backpressure:

<blockquote>Spark back pressure, which can be enabled by setting spark.streaming.backpressure.enabled=true, will dynamically resize batches so as to avoid queue build up. It is implemented using a Proportional Integral Derivative (PID) algorithm. This algorithm has some interesting properties, including the lack of guarantee of a stable fixed point. This can manifest itself not just in transient overshoot, but in a batch size oscillating around a (potentially optimal) constant throughput. The overshoot incurs latency; the undershoot costs throughput. Catastrophic overshoot leading to OOM is possible in degenerate circumstances (you need to choose the parameters quite deviously to cause this to happen). Having witnessed undershoot and slow recovery in production streaming jobs, I decided to investigate further by testing the algorithm with a simulator. </blockquote>

]]></description>
<dc:subject>backpressure streaming queueing pid-controllers algorithms congestion-control</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:eb53955f6313/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backpressure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pid-controllers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:congestion-control"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://segment.com/blog/introducing-centrifuge/">
    <title>Centrifuge: a reliable system for delivering billions of events per day</title>
    <dc:date>2018-07-11T12:12:36+00:00</dc:date>
    <link>https://segment.com/blog/introducing-centrifuge/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice scale-up service to solve the multi-tenant, multi-target queueing problem with good customer isolation from Segment]]></description>
<dc:subject>queueing architecture dead-letter-queue kafka segment multi-tenant isolation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:38ab90c50fc7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dead-letter-queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:segment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multi-tenant"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isolation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://atscaleconference.com/videos/cadence-microservice-architecture-beyond-requestreply/">
    <title>Cadence: Microservice architecture beyond request/reply – @Scale</title>
    <dc:date>2017-06-26T11:00:30+00:00</dc:date>
    <link>https://atscaleconference.com/videos/cadence-microservice-architecture-beyond-requestreply/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Uber’s request/reply handling middleware — based on the SWF API, it seems]]></description>
<dc:subject>swf apis microservices uber cadence asynchronous request-reply distcomp queueing middleware go</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f33a1bf556d4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cadence"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asynchronous"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:request-reply"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:middleware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://eng.uber.com/cherami/">
    <title>Cherami: Uber Engineering’s Durable and Scalable Task Queue in Go - Uber Engineering Blog</title>
    <dc:date>2016-12-14T11:21:39+00:00</dc:date>
    <link>https://eng.uber.com/cherami/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
a competing-consumer messaging queue that is durable, fault-tolerant, highly available and scalable. We achieve durability and fault-tolerance by replicating messages across storage hosts, and high availability by leveraging the append-only property of messaging queues and choosing eventual consistency as our basic model. Cherami is also scalable, as the design does not have single bottleneck. [...]
Cherami is completely written in Go, a language that makes building highly performant and concurrent system software a lot of fun. Additionally, Cherami uses several libraries that Uber has already open sourced: TChannel for RPC and Ringpop for health checking and group membership. Cherami depends on several third-party open source technologies: Cassandra for metadata storage, RocksDB for message storage, and many other third-party Go packages that are available on GitHub. We plan to open source Cherami in the near future.
</blockquote>]]></description>
<dc:subject>cherami uber queueing tasks queues architecture scalability go cassandra rocksdb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:08be41dbc892/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cherami"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tasks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rocksdb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-for-amazon-simple-queue-service-fifo-queues-with-exactly-once-delivery-deduplication/">
    <title>Simple Queue Service FIFO Queues with Exactly-Once Processing &amp; Deduplication</title>
    <dc:date>2016-11-18T13:13:17+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-for-amazon-simple-queue-service-fifo-queues-with-exactly-once-delivery-deduplication/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great, I've looked for this so many times.  Only tricky limit I can spot is the 300 tps limit, and it's US-East/US-West only for now]]></description>
<dc:subject>fifo queues queueing architecture aws sqs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:41a866c8fba4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fifo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/hystrixoss/mCCXEwSXb9M/bi_XHKIDAAAJ">
    <title>Should create a separate Hystrix Thread pool for each remote call?</title>
    <dc:date>2016-05-18T10:21:37+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/hystrixoss/mCCXEwSXb9M/bi_XHKIDAAAJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent advice on capacity planning and queueing theory, in the context of Hystrix.  Should I use a single thread pool for all dependency callouts, or independent thread pools for each one?]]></description>
<dc:subject>threadpools pooling hystrix capacity queue-theory queueing queues failure resilience soa microservices</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:64afc24a5d6c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pooling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hystrix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue-theory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resilience"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/conversant/disruptor">
    <title>Conversant ConcurrentQueue and Disruptor BlockingQueue</title>
    <dc:date>2016-03-07T11:24:20+00:00</dc:date>
    <link>https://github.com/conversant/disruptor</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Disruptor is the highest performing intra-thread transfer mechanism available in Java. Conversant Disruptor is the highest performing implementation of this type of ring buffer queue because it has almost no overhead and it exploits a particularly simple design.

Conversant has been using this in production since 2012 and the performance is excellent. The BlockingQueue implementation is very stable, although we continue to tune and improve it.  The latest release, 1.2.4, is 100% production ready.

Although we have been working on it for a long time, we decided to open source our BlockingQueue this year to contribute something back to the community. ... its a drop in for BlockingQueue, so its a very easy test.  Conversant Disruptor will crush ArrayBlockingQueue and LinkedTransferQueue for thread to thread transfers.    

In our system, we noticed a 10-20% reduction in overall system load and latency when we introduced it.']]></description>
<dc:subject>disruptor blocking-queues queues queueing data-structures algorithms java conversant concurrency performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:502056282b58/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disruptor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocking-queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:conversant"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you">
    <title>5 subtle ways you're using MySQL as a queue, and why it'll bite you</title>
    <dc:date>2016-01-06T12:42:41+00:00</dc:date>
    <link>https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent post from Percona. I particularly like that they don't just say "don't use MySQL" -- they give good advice on how it can be made work: 1) avoid polling; 2) avoid locking; and 3) avoid storing your queue in the same table as other data.]]></description>
<dc:subject>database mysql queueing queue messaging percona rds locking sql architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5081114f1b88/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.h">
    <title>wangle/Codel.h at master · facebook/wangle</title>
    <dc:date>2015-11-04T16:28:06+00:00</dc:date>
    <link>https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.h</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Facebook's open-source implementation of the CoDel queue management algorithm applied to server request-handling capacity in their C++ service bootstrap library, Wangle.]]></description>
<dc:subject>wangle facebook codel services capacity reliability queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:646392c5785b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wangle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:codel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.confluent.io/blog/apache-kafka-purgatory-hierarchical-timing-wheels">
    <title>Apache Kafka, Purgatory, and Hierarchical Timing Wheels</title>
    <dc:date>2015-10-29T16:37:01+00:00</dc:date>
    <link>http://www.confluent.io/blog/apache-kafka-purgatory-hierarchical-timing-wheels</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In the new design, we use Hierarchical Timing Wheels for the timeout timer and DelayQueue of timer buckets to advance the clock on demand. Completed requests are removed from the timer queue immediately with O(1) cost. The buckets remain in the delay queue, however, the number of buckets is bounded. And, in a healthy system, most of the requests are satisfied before timeout, and many of the buckets become empty before pulled out of the delay queue. Thus, the timer should rarely have the buckets of the lower interval. The advantage of this design is that the number of requests in the timer queue is the number of pending requests exactly at any time. This allows us to estimate the number of requests need to be purged. We can avoid unnecessary purge operation of the watcher lists. As the result we achieve a higher scalability in terms of request rate with much better CPU usage.</blockquote>

]]></description>
<dc:subject>algorithms timers kafka scheduling timing-wheels delayqueue queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:60858eeba501/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timing-wheels"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:delayqueue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.twitter.com/2015/flying-faster-with-twitter-heron">
    <title>Twitter ditches Storm</title>
    <dc:date>2015-06-04T10:04:02+00:00</dc:date>
    <link>https://blog.twitter.com/2015/flying-faster-with-twitter-heron</link>
    <dc:creator>jm</dc:creator><description><![CDATA[in favour of a proprietary ground-up rewrite called Heron.  Reading between the lines it sounds like Storm had problems with latency, reliability, data loss, and supporting back pressure.]]></description>
<dc:subject>analytics architecture twitter storm heron backpressure streaming realtime queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8bb89823ffcc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heron"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backpressure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.developer-tech.com/news/2014/jun/10/why-loggly-loves-apache-kafka-how-unbreakable-infinitely-scalable-messaging-makes-log-management-better/">
    <title>Why Loggly loves Apache Kafka</title>
    <dc:date>2015-05-06T11:19:20+00:00</dc:date>
    <link>http://www.developer-tech.com/news/2014/jun/10/why-loggly-loves-apache-kafka-how-unbreakable-infinitely-scalable-messaging-makes-log-management-better/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some good factoids about Loggly's Kafka usage and scales]]></description>
<dc:subject>scalability logging loggly kafka queueing ops reliabilty</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:61df5b7109a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:loggly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliabilty"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.forter.com/comparing-message-queue-architectures-on-aws/">
    <title>Comparing Message Queue Architectures on AWS</title>
    <dc:date>2015-02-03T00:40:40+00:00</dc:date>
    <link>http://tech.forter.com/comparing-message-queue-architectures-on-aws/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A good overview -- I like the summary table.  tl;dr: <blockquote>If you are light on DevOps and not latency sensitive use SQS for job management and Kinesis for event stream processing. If latency is an issue, use ELB or 2 RabbitMQs (or 2 beanstalkds) for job management and Redis for event stream processing.</blockquote>

]]></description>
<dc:subject>amazon architecture aws messaging queueing elb rabbitmq beanstalk kinesis sqs redis kafka</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ae3870806c75/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rabbitmq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:beanstalk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kinesis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/sclasen/event-shuttle">
    <title>sclasen/event-shuttle</title>
    <dc:date>2014-11-25T12:06:52+00:00</dc:date>
    <link>https://github.com/sclasen/event-shuttle</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>UNIX system service [jmason: ie a sidecar] that collects events and reliably delivers them to kafka, relieving other services on the same system from having to do so.  Journals events through bolt-db so that in the event of an kafka outage, events can still be accepted, and will be delivered when kafka becomes available.</blockquote>

]]></description>
<dc:subject>kafka messaging ruby go events fault-tolerance queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:58fdafc74a8c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:events"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html">
    <title>Aeron: Do we really need another messaging system? - High Scalability</title>
    <dc:date>2014-11-17T17:52:27+00:00</dc:date>
    <link>http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[excellent writeup on Aeron]]></description>
<dc:subject>aeron messing libraries java martin-thompson performance mechanical-sympathy queueing ipc tcp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:167738c3e8fa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aeron"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:martin-thompson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechanical-sympathy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://projects.eclipse.org/proposals/moquette-mqtt">
    <title>Moquette MQTT</title>
    <dc:date>2014-05-29T15:35:02+00:00</dc:date>
    <link>https://projects.eclipse.org/proposals/moquette-mqtt</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a Java implementation of an MQTT 3.1 broker. Its code base is small. At its core, Moquette is an events processor; this lets the code base be simple, avoiding thread sharing issues. The Moquette broker is lightweight and easy to understand so it could be embedded in other projects.</blockquote>

]]></description>
<dc:subject>mqtt moquette netty messaging queueing push-notifications iot internet push eclipse</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:258866cdaffb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mqtt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:moquette"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push-notifications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eclipse"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://psy-lob-saw.blogspot.ie/2014/04/notes-on-concurrent-ring-buffer-queue.html">
    <title>Notes On Concurrent Ring Buffer Queue Mechanics</title>
    <dc:date>2014-04-22T22:20:43+00:00</dc:date>
    <link>http://psy-lob-saw.blogspot.ie/2014/04/notes-on-concurrent-ring-buffer-queue.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great notes from Nitsan Wakart, who's been hacking on ringbuffers a lot in JAQ]]></description>
<dc:subject>jaq nitsanw atomic concurrency data-structures ring-buffers queueing queues algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ce4599f4a093/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jaq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nitsanw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atomic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ring-buffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://webcache.googleusercontent.com/search?q=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;oq=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;aqs=chrome..69i57j69i58.795j0j4&amp;sourceid=chrome&amp;espv=210&amp;es_sm=91&amp;ie=UTF-8">
    <title>TCP incast vs Riak</title>
    <dc:date>2014-02-14T15:36:17+00:00</dc:date>
    <link>http://webcache.googleusercontent.com/search?q=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;oq=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;aqs=chrome..69i57j69i58.795j0j4&amp;sourceid=chrome&amp;espv=210&amp;es_sm=91&amp;ie=UTF-8</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An extremely congested local network segment causes the "TCP incast" throughput collapse problem -- packet loss occurs, and TCP throughput collapses as a side effect.  So far, this is pretty unsurprising, and anyone designing a service needs to keep bandwidth requirements in mind.

However it gets worse with Riak.  Due to a bug, this becomes a serious issue for all clients: the Erlang network distribution port buffers fill up in turn, and the Riak KV vnode process (in its entirety) will be descheduled and 'cannot answer any more queries until the A-to-B network link becomes uncongested.'

This is where EC2's fully-uncontended-1:1-network compute cluster instances come in handy, btw. ;)]]></description>
<dc:subject>incast tcp networking bandwidth riak architecture erlang buffering queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:895ea7fbed24/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:incast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bandwidth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buffering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://reverbrain.com/grape/">
    <title>Grape</title>
    <dc:date>2013-11-20T12:36:47+00:00</dc:date>
    <link>http://reverbrain.com/grape/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a realtime processing engine, built on a persistent queue and a set of workers.  'The main goal is data availability and persistency.  We created grape for those who cannot afford losing data'.  It does this by allowing infinite expansion of the pending queue in Elliptics, their Dynamo-like horizontally-scaled storage backend.]]></description>
<dc:subject>kafka queue queueing storage realtime fault-tolerance grape cep event-processing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:269fc0b4ff60/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grape"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cep"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:event-processing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.michael-noll.com/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster-on-a-single-node/#excursus-topics-partitions-and-replication-in-kafka">
    <title>Running a Multi-Broker Apache Kafka 0.8 Cluster on a Single Node</title>
    <dc:date>2013-04-10T22:45:22+00:00</dc:date>
    <link>http://www.michael-noll.com/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster-on-a-single-node/#excursus-topics-partitions-and-replication-in-kafka</link>
    <dc:creator>jm</dc:creator><description><![CDATA[an excellent writeup on Kafka 0.8's use and operation, including details of the new replication features ]]></description>
<dc:subject>kafka replication queueing distributed ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8a53eb32ea1a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/">
    <title>Kafka 0.8 Producer Performance</title>
    <dc:date>2013-04-10T22:24:27+00:00</dc:date>
    <link>https://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great benchmarking from Piotr Kozikowski at the LiveRamp team, into performance of the upcoming Kafka 0.8 release]]></description>
<dc:subject>performance kafka apache benchmarks ops queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f67886faaa2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics">
    <title>Heroku finds out that distributed queueing is hard</title>
    <dc:date>2013-02-18T10:36:49+00:00</dc:date>
    <link>http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Stage 3 of the Rap Genius/Heroku blog drama.  Summary (as far as I can tell): Heroku gave up on a fully-synchronised load-balancing setup ("intelligent routing"), since it didn't scale, in favour of randomised queue selection; they didn't sufficiently inform their customers, and metrics and docs were not updated to make this change public; the pessimal case became pretty damn pessimal; a customer eventually noticed and complained publicly, creating a public shit-storm.

Comments: 1. this is why you monitor real HTTP request latency (scroll down for crazy graphs!).  2. include 90/99 percentiles to catch the "tail" of poorly-performing requests.  3. Load balancers are hard.

http://aphyr.com/posts/277-timelike-a-network-simulator has more info on the intricacies of distributed load balancing -- worth a read.]]></description>
<dc:subject>heroku rap-genius via:hn networking distcomp distributed load-balancing ip queueing percentiles monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:125334f62bdf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heroku"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rap-genius"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:hn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work">
    <title>How does LMAX's disruptor pattern work? - Stack Overflow</title>
    <dc:date>2011-11-23T09:52:35+00:00</dc:date>
    <link>http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work</link>
    <dc:creator>jm</dc:creator><description><![CDATA[LMAX's "Disruptor" concurrent-server pattern, claiming to be a higher-throughput, lower-latency, and lock-free alternative to the SEDA pattern using a massive ring buffer.  Good discussion here at SO.  (via Filippo)]]></description>
<dc:subject>via:filippo servers seda queueing concurrency disruptor patterns latency trading performance ring-buffers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:388ee9929e15/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:filippo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:seda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disruptor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ring-buffers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/nathanmarz/storm/wiki/Rationale">
    <title>Storm</title>
    <dc:date>2011-09-20T21:04:42+00:00</dc:date>
    <link>https://github.com/nathanmarz/storm/wiki/Rationale</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The past decade has seen a revolution in data processing. MapReduce, Hadoop, and related technologies have made it possible to store and process data at scales previously unthinkable. Unfortunately, these data processing technologies are not realtime systems, nor are they meant to be. There's no hack that will turn Hadoop into a realtime system; realtime data processing has a fundamentally different set of requirements than batch processing.

However, realtime data processing at massive scale is becoming more and more of a requirement for businesses. The lack of a "Hadoop of realtime" has become the biggest hole in the data processing ecosystem.  Storm fills that hole.'

]]></description>
<dc:subject>data scaling twitter realtime scalability storm queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0781f3875d18/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://devblog.bu.mp/how-we-use-redis-at-bump">
    <title>How we use Redis at Bump</title>
    <dc:date>2011-07-20T00:43:14+00:00</dc:date>
    <link>http://devblog.bu.mp/how-we-use-redis-at-bump</link>
    <dc:creator>jm</dc:creator><description><![CDATA[via Simon Willison.  some nice ideas here, particularly using a replication slave to handle the potentially latency-impacting disk writes in AOF mode]]></description>
<dc:subject>queueing redis nosql databases storage via:simonw replication bump</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:70e64dd1ac5d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:simonw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bump"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lists.openamq.org/pipermail/openamq-dev/2010-March/001598.html">
    <title>creators of AMQP ditching it for ZeroMQ</title>
    <dc:date>2010-03-31T11:01:16+00:00</dc:date>
    <link>http://lists.openamq.org/pipermail/openamq-dev/2010-March/001598.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['While iMatix was the original designer of AMQP and has invested hugely in that protocol, we believe it is fundamentally flawed, and unfixable.  It is too complex and the barriers to participation are massive.   We do not believe that it's in the best interest of our customers and users to invest further in AMQP.  Specifically, iMatix will be stepping out of the AMQP workgroup and will not be supporting AMQP/1.0 when that emerges, if it ever emerges.'  wow, massive downvote there]]></description>
<dc:subject>queueing amqp zeromq imatix mq protocols openamq via:janl</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:f3c179d80f3e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amqp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zeromq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:imatix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openamq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:janl"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://github.com/blog/542-introducing-resque">
    <title>Introducing Resque - GitHub</title>
    <dc:date>2009-11-05T22:22:53+00:00</dc:date>
    <link>http://github.com/blog/542-introducing-resque</link>
    <dc:creator>jm</dc:creator><description><![CDATA[github's take on a good, distributed queueing system in Ruby]]></description>
<dc:subject>ruby github queueing ipc resque</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:95ccce78d834/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resque"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>