<?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://brooker.co.za/blog/2023/01/06/erasure.html"/>
	<rdf:li rdf:resource="https://engineering.linkedin.com/blog/2022/real-time-analytics-on-network-flow-data-with-apache-pinot"/>
	<rdf:li rdf:resource="https://bitesizedserverless.com/bite/serverless-messaging-latency-compared/"/>
	<rdf:li rdf:resource="https://colin-scott.github.io/personal_website/research/interactive_latency.html"/>
	<rdf:li rdf:resource="https://arxiv.org/pdf/2001.06561.pdf"/>
	<rdf:li rdf:resource="https://sysdig.com/blog/golden-signals-kubernetes/"/>
	<rdf:li rdf:resource="https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html"/>
	<rdf:li rdf:resource="https://softwaremill.com/amazon-sqs-performance-latency/?__s=gf36pf8g1gjugcqh6ppo"/>
	<rdf:li rdf:resource="https://www.cloudping.co/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/dynamodb/dax/"/>
	<rdf:li rdf:resource="https://www.prerender.cloud/lambda-latency"/>
	<rdf:li rdf:resource="https://github.com/ztellman/dirigiste"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/mechanical-sympathy/0gaBXxFm4hE/O9QomwHIJAAJ"/>
	<rdf:li rdf:resource="http://danluu.com/perf-tracing/"/>
	<rdf:li rdf:resource="http://na.leagueoflegends.com/en/page/ping-winrate-and-vayne-probs"/>
	<rdf:li rdf:resource="http://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html"/>
	<rdf:li rdf:resource="https://labs.spotify.com/2015/12/08/els-part-1/"/>
	<rdf:li rdf:resource="https://www.informatica.com/downloads/1568_high_perf_messaging_wp/Topics-in-High-Performance-Messaging.htm"/>
	<rdf:li rdf:resource="http://www.seastar-project.org/"/>
	<rdf:li rdf:resource="https://github.com/h2non/toxy#latency"/>
	<rdf:li rdf:resource="http://blog.takipi.com/amazon-ec2-2015-benchmark-testing-speeds-between-aws-ec2-and-s3-regions/"/>
	<rdf:li rdf:resource="http://epickrram.blogspot.co.uk/2014/05/performance-testing-at-lmax-part-one.html"/>
	<rdf:li rdf:resource="http://www.solarflare.com/SolarCapture-Packet-Capture-Software"/>
	<rdf:li rdf:resource="https://timharris.uk/papers/2015-hotos.pdf"/>
	<rdf:li rdf:resource="http://arxiv.org/pdf/1504.02578.pdf"/>
	<rdf:li rdf:resource="https://groups.google.com/d/msg/mechanical-sympathy/DWlziVmyW-w/at-54WECjL4J"/>
	<rdf:li rdf:resource="http://www.evanjones.ca/jvm-mmap-pause.html"/>
	<rdf:li rdf:resource="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/marketplace/pp/B00M25ZRMC/ref=srh_res_product_title?ie=UTF8&amp;sr=0-2&amp;qid=1423925373136"/>
	<rdf:li rdf:resource="http://psy-lob-saw.blogspot.ie/2015/02/hdrhistogram-better-latency-capture.html"/>
	<rdf:li rdf:resource="http://sysdigcloud.com/aws-storage-latency-sysdig-spectrogram/"/>
	<rdf:li rdf:resource="https://github.com/tylertreat/Comcast"/>
	<rdf:li rdf:resource="https://github.com/giltene/wrk2"/>
	<rdf:li rdf:resource="https://twitter.com/giltene/status/530432078639161344"/>
	<rdf:li rdf:resource="https://groups.google.com/a/jclarity.com/forum/#!topic/friends/QPXl_8ce5Fg"/>
	<rdf:li rdf:resource="https://redislabs.com/blog/testing-fork-time-on-awsxen-infrastructure#.VFJgrFOsXFd"/>
	<rdf:li rdf:resource="http://latencytipoftheday.blogspot.ie/2014/06/latencytipoftheday-most-page-loads.html?m=1"/>
	<rdf:li rdf:resource="https://github.com/FelixGV/tehuti"/>
	<rdf:li rdf:resource="http://www.cs.ucsb.edu/~suri/psdir/ency.pdf"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/project-voldemort/Y52UyHQ8tBA/9Ei79_RvS3EJ"/>
	<rdf:li rdf:resource="http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf"/>
	<rdf:li rdf:resource="http://prophet.cs.duke.edu/courses/compsci590.4/fall13/838-CloudPapers/dean_longtail.pdf"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/mechanical-sympathy/g-iCw1HbZ-o/XXcQYb596X4J"/>
	<rdf:li rdf:resource="http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf"/>
	<rdf:li rdf:resource="http://kamon.io/presentations/javacro14/#/"/>
	<rdf:li rdf:resource="http://www.igvita.com/2014/04/21/uplink-scheduling-in-4G-networks/"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=7507377"/>
	<rdf:li rdf:resource="http://vanillajava.blogspot.co.uk/2013/07/micro-jitter-busy-waiting-and-binding.html?m=1"/>
	<rdf:li rdf:resource="https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final77.pdf"/>
	<rdf:li rdf:resource="http://latencyutils.github.io/LatencyUtils/"/>
	<rdf:li rdf:resource="http://www.cs.rutgers.edu/~muthu/bquant.pdf"/>
	<rdf:li rdf:resource="http://queue.acm.org/detail.cfm?id=2536492"/>
	<rdf:li rdf:resource="http://chimera.labs.oreilly.com/books/1230000000545"/>
	<rdf:li rdf:resource="http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2"/>
	<rdf:li rdf:resource="http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity"/>
	<rdf:li rdf:resource="http://attentionshard.wordpress.com/2013/09/30/why-tellybug-moved-from-cassandra-to-amazon-dynamodb/"/>
	<rdf:li rdf:resource="http://blog.meldium.com/home/2013/9/13/benchmarking-redis-on-aws-elasticache"/>
	<rdf:li rdf:resource="https://issues.apache.org/jira/browse/CASSANDRA-5582"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/mechanical-sympathy/icNZJejUHfE/BfDekfBEs_sJ"/>
	<rdf:li rdf:resource="http://blog.filepicker.io/post/29422604907/improved-https-performance-with-early-ssl-termination"/>
	<rdf:li rdf:resource="http://www.slideshare.net/sthair/measuring-mobile-web-performance-v2"/>
	<rdf:li rdf:resource="http://netsekure.org/2010/03/tls-overhead/"/>
	<rdf:li rdf:resource="http://www.bailis.org/blog/communication-costs-in-real-world-networks/"/>
	<rdf:li rdf:resource="http://developer.yahoo.com/blogs/ydn/posts/2013/02/storm-and-hadoop-convergence-of-big-data-and-low-latency-processing/"/>
	<rdf:li rdf:resource="http://www.altdevblogaday.com/2013/02/22/latency-mitigation-strategies/"/>
	<rdf:li rdf:resource="http://www.anandtech.com/show/6432/the-intel-ssd-dc-s3700-intels-3rd-generation-controller-analyzed/3"/>
	<rdf:li rdf:resource="http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work"/>
	<rdf:li rdf:resource="http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html"/>
	<rdf:li rdf:resource="http://lists.canonical.org/pipermail/kragen-tol/2010-June/000917.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://brooker.co.za/blog/2023/01/06/erasure.html">
    <title>Erasure Coding versus Tail Latency - Marc's Blog</title>
    <dc:date>2023-05-23T22:05:23+00:00</dc:date>
    <link>https://brooker.co.za/blog/2023/01/06/erasure.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A very neat trick via Marc Brooker to improve tail latencies using erasure coding:

'Say I have an in-memory cache of objects. I can keep any object in the cache once, and always go looking for it in that one place (e.g. with consistent hashing). If that place is slow, overloaded, experiencing packet loss, or whatever, I'll see high latency for all attempts to get that object. With hedging I can avoid that, if I store the object in two places rather than one, at the cost of doubling the size of my cache.

But what if I wanted to avoid the slowness and not double the size of my cache? Instead of storing everything twice, I could break it into (for example) 5 pieces .. encoded in such a way that I could reassemble it from any four pieces 
.. . Then, when I fetch, I send five get requests, and have the whole object as soon as four have returned. The overhead here on requests is 5x, on bandwidth is worst-case 20%, and on storage is 20%. The effect on tail latency can be considerable.']]></description>
<dc:subject>architecture cache storage tail-latencies performance marc-brooker lambda erasure-coding algorithms latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dbbb79c2955e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tail-latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:marc-brooker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erasure-coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.linkedin.com/blog/2022/real-time-analytics-on-network-flow-data-with-apache-pinot">
    <title>Real-time analytics on network flow data with Apache Pinot</title>
    <dc:date>2022-09-14T17:05:24+00:00</dc:date>
    <link>https://engineering.linkedin.com/blog/2022/real-time-analytics-on-network-flow-data-with-apache-pinot</link>
    <dc:creator>jm</dc:creator><description><![CDATA[LinkedIn are using Pinot for this use case, with a super-low-latency querying requirement:

<blockquote>InFlow requires storage of tens of TBs of data with a retention of 30 days. To support its real-time troubleshooting use case, the data must be queryable in real-time with sub-second latency so that engineers can query the data without any hassles during outages. For the storage layer, InFlow leverages Apache Pinot.</blockquote>

]]></description>
<dc:subject>pinot latency metrics linkedin network-flows realtime analytics storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d408bc8a0e1e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pinot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network-flows"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bitesizedserverless.com/bite/serverless-messaging-latency-compared/">
    <title>Serverless Messaging: Latency Compared</title>
    <dc:date>2022-09-07T08:46:07+00:00</dc:date>
    <link>https://bitesizedserverless.com/bite/serverless-messaging-latency-compared/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Various AWS queueing/messaging services' latencies compared in eu-west-1:

'When latency matters, there are a few obvious winners. SQS Standard can deliver a message to a consumer in as fast as 14 ms and is seldomly slower than 100 ms, assuming low batch sizes. Kinesis with Enhanced Fan-Out is only slightly slower and allows for multiple consumers and a long history of events. SNS falls in the low latency category too, although the SNS FIFO option includes more moving parts and thus a larger latency spread, up to half a second.
Step Functions and DynamoDB Streams take up the middle section, with P50 latencies up to about 200 ms.
The highest latency is introduced by EventBridge and Kinesis Data Streams without Enhanced Fan-Out. These services add at least a few hundred milliseconds to your integrations, but can easily run up to a second or more.']]></description>
<dc:subject>aws latency messaging queues architecture ops sqs sns kinesis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0fd2c91e94ef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<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:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kinesis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://colin-scott.github.io/personal_website/research/interactive_latency.html">
    <title>Numbers Every Programmer Should Know, By Year</title>
    <dc:date>2020-03-03T14:41:26+00:00</dc:date>
    <link>https://colin-scott.github.io/personal_website/research/interactive_latency.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interactively explore how Jeff Dean's "Numbers Every Programmer Should Know" have changed over time (via Kishore Gopalakrishna)]]></description>
<dc:subject>memory latency hardware history jeff-dean latencies speed performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c7ea2fc97e3c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jeff-dean"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/pdf/2001.06561.pdf">
    <title>Circllhist</title>
    <dc:date>2020-02-10T11:59:56+00:00</dc:date>
    <link>https://arxiv.org/pdf/2001.06561.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A Log-Linear Histogram Data Structure for IT Infrastructure Monitoring, Heinrich Hartmann, Theo Schlossnagle, (Submitted on 17 Jan 2020).

The circllhist histogram is a fast and memory efficient data structure for summarizing large numbers of latency measurements. It is particularly suited for applications in IT infrastructure monitoring, and provides nano-second data insertion, full mergeability, accurate approximation of quantiles with a-priori bounds on the relative error.

Open-source implementations are available for C/lua/python/Go/Java/JavaScript.'

The paper compares it against 'alternative data-structures which are employed in practice for aggregated quantile calculations: Prometheus Histograms, t-digest, [Gil Tene's] HDR Histograms, and DDSketches']]></description>
<dc:subject>histograms aggregation quantiles percentiles measurement graphs data-structures summaries latency monitoring approximation papers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:763bb560c156/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:histograms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aggregation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:summaries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://sysdig.com/blog/golden-signals-kubernetes/">
    <title>How to monitor Golden signals in Kubernetes</title>
    <dc:date>2020-01-09T17:19:22+00:00</dc:date>
    <link>https://sysdig.com/blog/golden-signals-kubernetes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Most of this doc is Kubernetes specific, but this "golden signals" idea is interesting; basically, the four metrics of requests per second, average request latency, CPU usage on service fleet, errors per second.  I would modify by adding the P99 or P99.9 request latency, and representing errors per second as a proportion of that period's request-per-second figure.]]></description>
<dc:subject>kubernetes monitoring sysdig golden-data k8s golden-signals metrics latency errors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c8f356dfeae1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysdig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golden-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golden-signals"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html">
    <title>KIAM defaults result in massive latencies on AWS API calls</title>
    <dc:date>2019-11-11T10:30:38+00:00</dc:date>
    <link>https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>KIAM [a Kubernetes IAM API helper] happens to provide short-lived credentials to Pods, which makes sense as it’s fair to assume that the average lifetime of a Pod is shorter than EC2 instances. The default is precisely 15 min.

But if you put both defaults together, you have a problem. Each certificate provided to the application has a 15 min expiration time. The AWS Java SDK will force refreshing any certificate with less than 15 min expiration time left.

The result is that every request will be forced to refresh the temporary certificate, which requires two calls to the AWS API that add a huge latency penalty to each request. We later found a feature request in the AWS Java SDK that mentions this same issue.

The fix was easy. We reconfigured KIAM to request credentials with a longer expiration period. Once this change was applied, requests started being served without involving the AWS Metadata service and returned to an even lower latency than in EC2.</blockquote>

]]></description>
<dc:subject>kubernetes kiam defaults aws latency performance ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6d5522f5c36/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kiam"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:defaults"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://softwaremill.com/amazon-sqs-performance-latency/?__s=gf36pf8g1gjugcqh6ppo">
    <title>SQS performance and latency</title>
    <dc:date>2017-07-10T15:03:12+00:00</dc:date>
    <link>https://softwaremill.com/amazon-sqs-performance-latency/?__s=gf36pf8g1gjugcqh6ppo</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some decent benchmark data on SQS:

<blockquote>We were looking at four values in the tests:
total number of messages sent per second (by all nodes)
total number of messages received per second
95th percentile of message send latency (how fast a message send call completes)
95th percentile of message processing latency (how long it takes between sending and receiving a message)</blockquote>

]]></description>
<dc:subject>sqs benchmarking measurement aws latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2438680a6eb8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.cloudping.co/">
    <title>AWS Inter-Region Latency Monitoring</title>
    <dc:date>2017-06-12T09:51:31+00:00</dc:date>
    <link>https://www.cloudping.co/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[only averages, though, no percentiles]]></description>
<dc:subject>latency networking aws ops inter-region cross-region ping</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ee529fc0773f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:inter-region"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cross-region"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ping"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/dynamodb/dax/">
    <title>Amazon DynamoDB Accelerator (DAX)</title>
    <dc:date>2017-04-20T10:36:09+00:00</dc:date>
    <link>https://aws.amazon.com/dynamodb/dax/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second. DAX does all the heavy lifting required to add in-memory acceleration to your DynamoDB tables, without requiring developers to manage cache invalidation, data population, or cluster management.</blockquote>

No latency percentile figures, unfortunately.  Also still in preview.]]></description>
<dc:subject>amazon dynamodb aws dax performance storage databases latency low-latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cff8a162539c/</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:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.prerender.cloud/lambda-latency">
    <title>AWS latency comparison: API Gateway vs Lambda vs Bare EC2</title>
    <dc:date>2016-10-12T11:04:22+00:00</dc:date>
    <link>https://www.prerender.cloud/lambda-latency</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ugh, 213ms mean response overhead]]></description>
<dc:subject>aws latency lambda api-gateway architecture http</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:afa22c5b2f10/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api-gateway"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ztellman/dirigiste">
    <title>ztellman/dirigiste</title>
    <dc:date>2016-06-01T11:55:13+00:00</dc:date>
    <link>https://github.com/ztellman/dirigiste</link>
    <dc:creator>jm</dc:creator><description><![CDATA['centrally-planned object and thread pools' for java.

'In the default JVM thread pools, once a thread is created it will only be retired when it hasn't performed a task in the last minute. In practice, this means that there are as many threads as the peak historical number of concurrent tasks handled by the pool, forever. These thread pools are also poorly instrumented, making it difficult to tune their latency or throughput.  Dirigiste provides a fast, richly instrumented version of a java.util.concurrent.ExecutorService, and provides a means to feed that instrumentation into a control mechanism that can grow or shrink the pool as needed. Default implementations that optimize the pool size for thread utilization are provided.  It also provides an object pool mechanism that uses a similar feedback mechanism to resize itself, and is significantly simpler than the Apache Commons object pool implementation.'

Great metric support, too.]]></description>
<dc:subject>async jvm dirigiste java threadpools concurrency utilization capacity executors object-pools object-pooling latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5092c7f0c12e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dirigiste"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utilization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:executors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pooling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/mechanical-sympathy/0gaBXxFm4hE/O9QomwHIJAAJ">
    <title>Gil Tene on benchmarking</title>
    <dc:date>2016-04-12T10:09:33+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/mechanical-sympathy/0gaBXxFm4hE/O9QomwHIJAAJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA['I would strongly encourage you to avoid repeating the mistakes of testing methodologies that focus entirely on max achievable throughput and then report some (usually bogus) latency stats at those max throughout modes. The techempower numbers are a classic example of this in play, and while they do provide some basis for comparing a small aspect of behavior (what I call the "how fast can this thing drive off a cliff" comparison, or "pedal to the metal" testing), those results are not very useful for comparing load carrying capacities for anything that actually needs to maintain some form of responsiveness SLA or latency spectrum requirements.'

Some excellent advice here on how to measure and represent stack performance.

Also: 'DON'T use or report standard deviation for latency. Ever. Except if you mean it as a joke.']]></description>
<dc:subject>performance benchmarking testing speed gil-tene latency measurement hdrhistogram load-testing load</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ddfcf3faf5bb/</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:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hdrhistogram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://danluu.com/perf-tracing/">
    <title>The Nyquist theorem and limitations of sampling profilers today, with glimpses of tracing tools from the future</title>
    <dc:date>2016-02-09T12:55:23+00:00</dc:date>
    <link>http://danluu.com/perf-tracing/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Awesome post from Dan Luu with data from Google:

<blockquote>The cause [of some mystery widespread 250ms hangs] was kernel throttling of the CPU for processes that went beyond their usage quota. To enforce the quota, the kernel puts all of the relevant threads to sleep until the next multiple of a quarter second. When the quarter-second hand of the clock rolls around, it wakes up all the threads, and if those threads are still using too much CPU, the threads get put back to sleep for another quarter second. The phase change out of this mode happens when, by happenstance, there aren’t too many requests in a quarter second interval and the kernel stops throttling the threads.  After finding the cause, an engineer found that this was happening on 25% of disk servers at Google, for an average of half an hour a day, with periods of high latency as long as 23 hours. This had been happening for three years. Dick Sites says that fixing this bug paid for his salary for a decade. This is another bug where traditional sampling profilers would have had a hard time. The key insight was that the slowdowns were correlated and machine wide, which isn’t something you can see in a profile.</blockquote>

]]></description>
<dc:subject>debugging performance visualization instrumentation metrics dan-luu latency google dick-sites linux scheduler throttling kernel hangs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:670193c955f5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:visualization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instrumentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dan-luu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dick-sites"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:throttling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hangs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://na.leagueoflegends.com/en/page/ping-winrate-and-vayne-probs">
    <title>League of Legends win-rates vs latency analysed</title>
    <dc:date>2015-12-15T12:02:11+00:00</dc:date>
    <link>http://na.leagueoflegends.com/en/page/ping-winrate-and-vayne-probs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>It appears that more mechanically intensive champions are more affected by latency, while tankier champions or those with point-and-click abilities are less affected by latency.</blockquote>

(via Nelson)]]></description>
<dc:subject>games league-of-legends latency ping gaming internet via:nelson</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fc8a4454ba09/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:league-of-legends"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html">
    <title>Low-latency journalling file write latency on Linux</title>
    <dc:date>2015-12-09T14:58:39+00:00</dc:date>
    <link>http://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great research from LMAX: xfs/ext4 are the best choices, and they explain why in detail, referring to the code]]></description>
<dc:subject>linux xfs ext3 ext4 filesystems lmax performance latency journalling ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9b225ebb15c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ext3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ext4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lmax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:journalling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://labs.spotify.com/2015/12/08/els-part-1/">
    <title>ELS: latency based load balancer, part 1</title>
    <dc:date>2015-12-09T14:28:29+00:00</dc:date>
    <link>https://labs.spotify.com/2015/12/08/els-part-1/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>ELS measures the following things:

Success latency and success rate of each machine;
Number of outstanding requests between the load balancer and each machine. These are the requests that have been sent out but we haven’t yet received a reply;
Fast failures are better than slow failures, so we also measure failure latency for each machine.

Since users care a lot about latency, we prefer machines that are expected to answer quicker. ELS therefore converts all the measured metrics into expected latency from the client’s perspective.[...]

In short, the formula ensures that slower machines get less traffic and failing machines get much less traffic. Slower and failing machines still get some traffic, because we need to be able to detect when they come back up again.</blockquote>

]]></description>
<dc:subject>latency spotify proxies load-balancing els algorithms c3 round-robin load-balancers routing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:067ff62fa178/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spotify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proxies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:els"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:round-robin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.informatica.com/downloads/1568_high_perf_messaging_wp/Topics-in-High-Performance-Messaging.htm">
    <title>Topics in High-Performance Messaging</title>
    <dc:date>2015-12-02T15:53:00+00:00</dc:date>
    <link>https://www.informatica.com/downloads/1568_high_perf_messaging_wp/Topics-in-High-Performance-Messaging.htm</link>
    <dc:creator>jm</dc:creator><description><![CDATA['We have worked together in the field of high-performance messaging for many years, and in that time, have seen some messaging systems that worked well and some that didn't. Successful deployment of a messaging system requires background information that is not easily available; most of what we know, we had to learn in the school of hard knocks. To save others a knock or two, we have collected here the essential background information and commentary on some of the issues involved in successful deployments. This information is organized as a series of topics around which there seems to be confusion or uncertainty. Please contact us if you have questions or comments.']]></description>
<dc:subject>messaging scalability scaling performance udp tcp protocols multicast latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aef1848d9376/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multicast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.seastar-project.org/">
    <title>Seastar</title>
    <dc:date>2015-09-24T14:51:09+00:00</dc:date>
    <link>http://www.seastar-project.org/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[C++ high-performance app framework; 'currently focused on high-throughput, low-latency I/O intensive applications.'

Scylla (Cassandra-compatible NoSQL store) is written in this.]]></description>
<dc:subject>c++ opensource performance framework scylla seastar latency linux shared-nothing multicore</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:44d66d8d03e7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:opensource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:seastar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shared-nothing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multicore"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/h2non/toxy#latency">
    <title>toxy</title>
    <dc:date>2015-08-28T11:19:51+00:00</dc:date>
    <link>https://github.com/h2non/toxy#latency</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>toxy is a fully programmatic and hackable HTTP proxy to simulate server failure scenarios and unexpected network conditions. It was mainly designed for fuzzing/evil testing purposes, when toxy becomes particularly useful to cover fault tolerance and resiliency capabilities of a system, especially in service-oriented architectures, where toxy may act as intermediate proxy among services.

toxy allows you to plug in poisons, optionally filtered by rules, which essentially can intercept and alter the HTTP flow as you need, performing multiple evil actions in the middle of that process, such as limiting the bandwidth, delaying TCP packets, injecting network jitter latency or replying with a custom error or status code.</blockquote>

]]></description>
<dc:subject>toxy proxies proxy http mitm node.js soa network failures latency slowdown jitter bandwidth tcp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4cc87b3a400a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:toxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proxies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mitm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:node.js"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slowdown"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bandwidth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.takipi.com/amazon-ec2-2015-benchmark-testing-speeds-between-aws-ec2-and-s3-regions/">
    <title>Amazon EC2 2015 Benchmark: Testing Speeds Between AWS EC2 and S3 Regions</title>
    <dc:date>2015-08-11T10:03:51+00:00</dc:date>
    <link>http://blog.takipi.com/amazon-ec2-2015-benchmark-testing-speeds-between-aws-ec2-and-s3-regions/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Here we are again, a year later, and still no bloody percentiles! Just amateurish averaging.  This is not how you measure anything, ffs.  Still, better than nothing I suppose]]></description>
<dc:subject>fail latency measurement aws ec2 percentiles s3</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4e5264c55d58/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://epickrram.blogspot.co.uk/2014/05/performance-testing-at-lmax-part-one.html">
    <title>Performance Testing at LMAX</title>
    <dc:date>2015-06-03T12:49:58+00:00</dc:date>
    <link>http://epickrram.blogspot.co.uk/2014/05/performance-testing-at-lmax-part-one.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good series of blog posts on the LMAX trading platform's performance testing strategy -- they capture live traffic off the wire, then build statistical models simulating its features.  See also http://epickrram.blogspot.co.uk/2014/07/performance-testing-at-lmax-part-two.html and http://epickrram.blogspot.co.uk/2014/08/performance-testing-at-lmax-part-three.html .]]></description>
<dc:subject>performance testing tests simulation latency lmax trading sniffing packet-capture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c962c123de77/</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:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tests"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lmax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sniffing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-capture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.solarflare.com/SolarCapture-Packet-Capture-Software">
    <title>SolarCapture Packet Capture Software</title>
    <dc:date>2015-05-18T09:31:39+00:00</dc:date>
    <link>http://www.solarflare.com/SolarCapture-Packet-Capture-Software</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting product line -- I didn't know this existed, but it makes good sense as a "network flight recorder".  Big in finance.

<blockquote>SolarCapture is powerful packet capture product family that can transform every server into a precision network monitoring device, increasing network visibility, network instrumentation, and performance analysis. SolarCapture products optimize network monitoring and security, while eliminating the need for specialized appliances, expensive adapters relying on exotic protocols, proprietary hardware, and dedicated networking equipment.</blockquote>

See also Corvil (based in Dublin!): 'I'm using a Corvil at the moment and it's awesome- nanosecond precision latency measurements on the wire.'

(via mechanical sympathy list)]]></description>
<dc:subject>corvil timing metrics measurement latency network solarcapture packet-capture financial performance security network-monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:04ed77af0e50/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corvil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:solarcapture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-capture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:financial"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network-monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://timharris.uk/papers/2015-hotos.pdf">
    <title>&quot;Trash Day: Coordinating Garbage Collection in Distributed Systems&quot;</title>
    <dc:date>2015-05-06T16:34:59+00:00</dc:date>
    <link>https://timharris.uk/papers/2015-hotos.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Another GC-coordination strategy, similar to Blade (qv), with some real-world examples using Cassandra]]></description>
<dc:subject>blade via:adriancolyer papers gc distsys algorithms distributed java jvm latency spark cassandra</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf80614a2fb9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blade"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:adriancolyer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distsys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/pdf/1504.02578.pdf">
    <title>_Blade: a Data Center Garbage Collector_</title>
    <dc:date>2015-04-17T09:46:59+00:00</dc:date>
    <link>http://arxiv.org/pdf/1504.02578.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Essentially, add a central GC scheduler to improve tail latencies in a cluster, by taking instances out of the pool to perform slow GC activity instead of letting them impact live operations.  I've been toying with this idea for a while, nice to see a solid paper about it]]></description>
<dc:subject>gc latency tail-latencies papers blade go java scheduling clustering load-balancing low-latency performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:604440c5b5eb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tail-latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blade"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clustering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/d/msg/mechanical-sympathy/DWlziVmyW-w/at-54WECjL4J">
    <title>Gil Tene's &quot;usual suspects&quot; to reduce system-level hiccups/latency jitters in a Linux system</title>
    <dc:date>2015-04-06T20:27:37+00:00</dc:date>
    <link>https://groups.google.com/d/msg/mechanical-sympathy/DWlziVmyW-w/at-54WECjL4J</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Based on empirical evidence (across many tens of sites thus far) and note-comparing with others, I use a list of "usual suspects" that I blame whenever they are not set to my liking and system-level hiccups are detected. Getting these settings right from the start often saves a bunch of playing around (and no, there is no "priority" to this - you should set them all right before looking for more advice...).</blockquote>

]]></description>
<dc:subject>performance latency hiccups gil-tene tuning mechanical-sympathy hyperthreading linux ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e22d85fc3109/</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:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiccups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechanical-sympathy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperthreading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.evanjones.ca/jvm-mmap-pause.html">
    <title>The Four Month Bug: JVM statistics cause garbage collection pauses (evanjones.ca)</title>
    <dc:date>2015-03-26T22:16:21+00:00</dc:date>
    <link>http://www.evanjones.ca/jvm-mmap-pause.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ugh, tying GC safepoints to disk I/O? bad idea:

<blockquote>The JVM by default exports statistics by mmap-ing a file in /tmp (hsperfdata). On Linux, modifying a mmap-ed file can block until disk I/O completes, which can be hundreds of milliseconds. Since the JVM modifies these statistics during garbage collection and safepoints, this causes pauses that are hundreds of milliseconds long. To reduce worst-case pause latencies, add the -XX:+PerfDisableSharedMem JVM flag to disable this feature. This will break tools that read this file, like jstat.</blockquote>

]]></description>
<dc:subject>bugs gc java jvm disk mmap latency ops jstat</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a8b7f0defa11/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mmap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jstat"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/">
    <title>JClarity's Illuminate</title>
    <dc:date>2015-02-26T15:49:43+00:00</dc:date>
    <link>http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Performance-diagnosis-as-a-service. Cool.

<blockquote>Users download and install an Illuminate Daemon using a simple installer which starts up a small stand alone Java process. The Daemon sits quietly unless it is asked to start gathering SLA data and/or to trigger a diagnosis. Users can set SLA’s via the dashboard and can opt to collect latency measurements of their transactions manually (using our library) or by asking Illuminate to automatically instrument their code (Servlet and JDBC based transactions are currently supported).

SLA latency data for transactions is collected on a short cycle. When the moving average of latency measurements goes above the SLA value (e.g. 150ms), a diagnosis is triggered. The diagnosis is very quick, gathering key data from O/S, JVM(s), virtualisation and other areas of the system. The data is then run through the machine learned algorithm which will quickly narrow down the possible causes and gather a little extra data if needed.

Once Illuminate has determined the root cause of the performance problem, the diagnosis report is sent back to the dashboard and an alert is sent to the user. That alert contains a link to the result of the diagnosis which the user can share with colleagues. Illuminate has all sorts of backoff strategies to ensure that users don’t get too many alerts of the same type in rapid succession!</blockquote>

]]></description>
<dc:subject>illuminate jclarity java jvm scala latency gc tuning performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d8f4dcc75538/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:illuminate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jclarity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/marketplace/pp/B00M25ZRMC/ref=srh_res_product_title?ie=UTF8&amp;sr=0-2&amp;qid=1423925373136">
    <title>Azul Zing on Ubuntu on AWS Marketplace</title>
    <dc:date>2015-02-18T23:18:00+00:00</dc:date>
    <link>https://aws.amazon.com/marketplace/pp/B00M25ZRMC/ref=srh_res_product_title?ie=UTF8&amp;sr=0-2&amp;qid=1423925373136</link>
    <dc:creator>jm</dc:creator><description><![CDATA[hmmm, very interesting -- the super-low-latency Zing JVM is available as a commercial EC2 instance type, at costs less than the EC2 instance price]]></description>
<dc:subject>zing azul latency performance ec2 aws</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:093f5794163a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azul"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://psy-lob-saw.blogspot.ie/2015/02/hdrhistogram-better-latency-capture.html">
    <title>HdrHistogram: A better latency capture method</title>
    <dc:date>2015-02-16T11:27:54+00:00</dc:date>
    <link>http://psy-lob-saw.blogspot.ie/2015/02/hdrhistogram-better-latency-capture.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An excellent intro to HdrHistogram usage]]></description>
<dc:subject>hdrhistogram hdr histograms statistics latency measurement metrics percentiles quantiles gil-tene nitsan-wakart</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fe1e9f2ecc3d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hdrhistogram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hdr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:histograms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nitsan-wakart"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sysdigcloud.com/aws-storage-latency-sysdig-spectrogram/">
    <title>Visualizing AWS Storage with Real-Time Latency Spectrogram</title>
    <dc:date>2015-01-27T23:33:56+00:00</dc:date>
    <link>http://sysdigcloud.com/aws-storage-latency-sysdig-spectrogram/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ohhhh this is very nice indeed.  Great viz!]]></description>
<dc:subject>dataviz latency io ops sysdig charts graphs commandline linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:395dfb4e90a0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataviz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:io"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysdig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:commandline"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/tylertreat/Comcast">
    <title>Comcast</title>
    <dc:date>2015-01-27T16:15:05+00:00</dc:date>
    <link>https://github.com/tylertreat/Comcast</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice wrapper for 'tc' and 'netem', for network latency/packet loss emulation]]></description>
<dc:subject>networking testing linux tc netem latency packet-loss iptables</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:99e8ef481d50/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-loss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iptables"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/giltene/wrk2">
    <title>wrk2</title>
    <dc:date>2014-11-10T15:45:50+00:00</dc:date>
    <link>https://github.com/giltene/wrk2</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A constant throughput, correct latency-recording variant of wrk.  This is a must-have when measuring network service latency --  corrects for Coordinated Omission error:

<blockquote>wrk's model, which is similar to the model found in many current load generators, computes the latency for a given request as the time from the sending of the first byte of the request to the time the complete response was received.  While this model correctly measures the actual completion time of individual requests, it exhibits a strong Coordinated Omission effect, through which most of the high latency artifacts exhibited by the measured server will be ignored. Since each connection will only begin to send a request after receiving a response, high latency responses result in the load generator coordinating with the server to avoid measurement during high latency periods.</blockquote>]]></description>
<dc:subject>wrk latency measurement tools cli http load-testing testing load-generation coordinated-omission gil-tene</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c02e86f370b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wrk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-generation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coordinated-omission"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/giltene/status/530432078639161344">
    <title>testing latency measurements using CTRL-Z</title>
    <dc:date>2014-11-06T19:18:11+00:00</dc:date>
    <link>https://twitter.com/giltene/status/530432078639161344</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An excellent tip from Gil "HDRHistogram" Tene:

<blockquote>Good example of why I always "calibrate" latency tools with ^Z tests. If ^Z results don't make sense, don't use [the] tool.  ^Z test math examples: If you ^Z for half the time, Max is obvious. [90th percentile] should be 80% of the ^Z stall time.</blockquote>

]]></description>
<dc:subject>control-z suspend unix testing latencies latency measurement percentiles tips</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:588d9f8b5c90/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:control-z"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:suspend"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/a/jclarity.com/forum/#!topic/friends/QPXl_8ce5Fg">
    <title>Linux kernel's Transparent Huge Pages feature causing 300ms-800ms pauses</title>
    <dc:date>2014-11-04T18:05:19+00:00</dc:date>
    <link>https://groups.google.com/a/jclarity.com/forum/#!topic/friends/QPXl_8ce5Fg</link>
    <dc:creator>jm</dc:creator><description><![CDATA[bad news for low-latency apps.  See also its impact on redis: http://antirez.com/news/84]]></description>
<dc:subject>redis memory defrag huge-pages linux kernel ops latency performance transparent-huge-pages</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:02aad4ff8ea8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:defrag"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:huge-pages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transparent-huge-pages"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://redislabs.com/blog/testing-fork-time-on-awsxen-infrastructure#.VFJgrFOsXFd">
    <title>Testing fork time on AWS/Xen infrastructure</title>
    <dc:date>2014-10-30T16:03:54+00:00</dc:date>
    <link>https://redislabs.com/blog/testing-fork-time-on-awsxen-infrastructure#.VFJgrFOsXFd</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Redis uses forking to perform persistence flushes, which means that once every 30 minutes it performs like crap (and kills the 99th percentile latency).  Given this, various Redis people have been benchmarking fork() times on various Xen platforms, since Xen has a crappy fork() implementation]]></description>
<dc:subject>fork xen redis bugs performance latency p99</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:097ee6064211/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fork"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p99"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://latencytipoftheday.blogspot.ie/2014/06/latencytipoftheday-most-page-loads.html?m=1">
    <title>Most page loads will experience the 99th percentile response latency</title>
    <dc:date>2014-10-29T12:25:45+00:00</dc:date>
    <link>http://latencytipoftheday.blogspot.ie/2014/06/latencytipoftheday-most-page-loads.html?m=1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>MOST of the page view attempts will experience the 99%'lie server response time in modern web applications. You didn't read that wrong.</blockquote>

]]></description>
<dc:subject>latency metrics percentiles p99 web http soa</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:46b1477c7ddd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p99"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/FelixGV/tehuti">
    <title>FelixGV/tehuti</title>
    <dc:date>2014-10-09T10:53:00+00:00</dc:date>
    <link>https://github.com/FelixGV/tehuti</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Felix says: 

'Like I said, I'd like to move it to a more general / non-personal repo in the future, but haven't had the time yet. Anyway, you can still browse the code there for now. It is not a big code base so not that hard to wrap one's mind around it.

It is Apache licensed and both Kafka and Voldemort are using it so I would say it is pretty self-contained (although Kafka has not moved to Tehuti proper, it is essentially the same code they're using, minus a few small fixes missing that we added).

Tehuti is a bit lower level than CodaHale (i.e.: you need to choose exactly which stats you want to measure and the boundaries of your histograms), but this is the type of stuff you would build a wrapper for and then re-use within your code base. For example: the Voldemort RequestCounter class.']]></description>
<dc:subject>asl2 apache open-source tehuti metrics percentiles quantiles statistics measurement latency kafka voldemort linkedin</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a2f55ebce7bb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asl2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tehuti"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cs.ucsb.edu/~suri/psdir/ency.pdf">
    <title>&quot;Quantiles on Streams&quot; [paper, 2009]</title>
    <dc:date>2014-10-08T09:49:58+00:00</dc:date>
    <link>http://www.cs.ucsb.edu/~suri/psdir/ency.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Chiranjeeb Buragohain and Subhash Suri: "Quantiles on Streams" in Encyclopedia of Database Systems, Springer, pp 2235–2240, 2009. ISBN: 978-0-387-35544-3', cited by Martin Kleppman in http://mail-archives.apache.org/mod_mbox/kafka-dev/201402.mbox/%3C131A7649-ED57-45CB-B4D6-F34063267664@linkedin.com%3E as a good, short literature survey re estimating percentiles with a small memory footprint.]]></description>
<dc:subject>latency percentiles coding quantiles streams papers algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:662952253d16/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/project-voldemort/Y52UyHQ8tBA/9Ei79_RvS3EJ">
    <title>Tehuti</title>
    <dc:date>2014-10-08T09:45:50+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/project-voldemort/Y52UyHQ8tBA/9Ei79_RvS3EJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An embryonic metrics library for Java/Scala from Felix GV at LinkedIn, extracted from Kafka's metric implementation and in the new Voldemort release.  It fixes the major known problems with the Meter/Timer implementations in Coda-Hale/Dropwizard/Yammer Metrics.

'Regarding Tehuti: it has been extracted from Kafka's metric implementation. The code was originally written by Jay Kreps, and then maintained improved by some Kafka and Voldemort devs, so it definitely is not the work of just one person. It is in my repo at the moment but I'd like to put it in a more generally available (git and maven) repo in the future. I just haven't had the time yet...

As for comparing with CodaHale/Yammer, there were a few concerns with it, but the main one was that we didn't like the exponentially decaying histogram implementation. While that implementation is very appealing in terms of (low) memory usage, it has several misleading characteristics (a lack of incoming data points makes old measurements linger longer than they should, and there's also a fairly high possiblity of losing interesting outlier data points). This makes the exp decaying implementation robust in high throughput fairly constant workloads, but unreliable in sparse or spiky workloads. The Tehuti implementation provides semantics that we find easier to reason with and with a small code footprint (which we consider a plus in terms of maintainability). Of course, it is still a fairly young project, so it could be improved further.'

More background at the kafka-dev thread: http://mail-archives.apache.org/mod_mbox/kafka-dev/201402.mbox/%3C131A7649-ED57-45CB-B4D6-F34063267664@linkedin.com%3E]]></description>
<dc:subject>kafka metrics dropwizard java scala jvm timers ewma statistics measurement latency sampling tehuti voldemort linkedin jay-kreps</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b56664c1a098/</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:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropwizard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ewma"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sampling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tehuti"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jay-kreps"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf">
    <title>&quot;Left-Right: A Concurrency Control Technique with Wait-Free Population Oblivious Reads&quot; [pdf]</title>
    <dc:date>2014-09-17T14:29:55+00:00</dc:date>
    <link>http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['In this paper, we describe a generic concurrency control technique with Blocking write operations and Wait-Free Population Oblivious read operations, which we named the Left-Right technique. It is of particular interest for real-time applications with dedicated Reader threads, due to its wait-free property that gives strong latency guarantees and, in addition, there is no need for automatic Garbage Collection.
The Left-Right pattern can be applied to any data structure, allowing concurrent access to it similarly to a Reader-Writer lock, but in a non-blocking manner for reads. We present several variations of the Left-Right technique, with different versioning mechanisms and state machines. In addition, we constructed an optimistic approach that can reduce synchronization for reads.'

See also http://concurrencyfreaks.blogspot.ie/2013/12/left-right-concurrency-control.html for java implementation code.]]></description>
<dc:subject>left-right concurrency multithreading wait-free blocking realtime gc latency reader-writer locking synchronization java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:71e20ba2b8b1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:left-right"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multithreading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wait-free"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reader-writer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://prophet.cs.duke.edu/courses/compsci590.4/fall13/838-CloudPapers/dean_longtail.pdf">
    <title>&quot;The Tail at Scale&quot;</title>
    <dc:date>2014-07-08T16:58:49+00:00</dc:date>
    <link>http://prophet.cs.duke.edu/courses/compsci590.4/fall13/838-CloudPapers/dean_longtail.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[by Jeffrey Dean and Luiz Andre Barroso, Google.  A selection of Google's architectural mechanisms used to defeat 99th-percentile latency spikes: hedged requests, tied requests, micro-partitioning, selective replication, latency-induced probation, canary requests.]]></description>
<dc:subject>google architecture distcomp soa http partitioning replication latency 99th-percentile canary-requests hedged-requests</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:eb38667ad2a8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:partitioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:99th-percentile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:canary-requests"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hedged-requests"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/mechanical-sympathy/g-iCw1HbZ-o/XXcQYb596X4J">
    <title>How to perform a load/latency test, correcting for coordinated-omission error</title>
    <dc:date>2014-07-03T14:05:19+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/mechanical-sympathy/g-iCw1HbZ-o/XXcQYb596X4J</link>
    <dc:creator>jm</dc:creator><description><![CDATA[p-code from Gil Tene]]></description>
<dc:subject>gil-tene coordinated-omission measurement jmh latency testing errors code</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c98b6e03164d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coordinated-omission"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf">
    <title>Google's Pegasus</title>
    <dc:date>2014-06-18T15:48:28+00:00</dc:date>
    <link>http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a power-management subsystem for warehouse-scale computing farms.  "It adjusts the power-performance settings of servers so that the overall workload barely meets its latency constraints for user queries."]]></description>
<dc:subject>pegasus power-management power via:fanf google latency scaling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ddece9bbccdf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pegasus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power-management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://kamon.io/presentations/javacro14/#/">
    <title>Monitoring Reactive Applications with Kamon</title>
    <dc:date>2014-05-19T10:41:38+00:00</dc:date>
    <link>http://kamon.io/presentations/javacro14/#/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["quality monitoring tools for apps built in Akka, Spray and Play!".  Uses Gil Tene's HDRHistogram and dropwizard Metrics under the hood.]]></description>
<dc:subject>metrics dropwizard hdrhistogram gil-tene kamon akka spray play reactive statistics java scala percentiles latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dd1798009833/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropwizard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hdrhistogram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kamon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:akka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spray"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:play"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reactive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.igvita.com/2014/04/21/uplink-scheduling-in-4G-networks/">
    <title>Uplink Latency of WiFi and 4G Networks</title>
    <dc:date>2014-04-22T22:33:14+00:00</dc:date>
    <link>http://www.igvita.com/2014/04/21/uplink-scheduling-in-4G-networks/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It's high. Wifi in particular shows high variability and long latency tails]]></description>
<dc:subject>wifi 3g 4g mobile networking internet latency tcp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2add3215a9fb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:4g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=7507377">
    <title>Game servers: UDP vs TCP</title>
    <dc:date>2014-04-01T21:49:21+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=7507377</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this HN thread on the age-old UDP vs TCP question is way better than the original post -- lots of salient comments]]></description>
<dc:subject>udp tcp games protocols networking latency internet gaming hackernews</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1876270a5c09/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hackernews"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://vanillajava.blogspot.co.uk/2013/07/micro-jitter-busy-waiting-and-binding.html?m=1">
    <title>Micro jitter, busy waiting and binding CPUs</title>
    <dc:date>2014-03-21T11:26:50+00:00</dc:date>
    <link>http://vanillajava.blogspot.co.uk/2013/07/micro-jitter-busy-waiting-and-binding.html?m=1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[pinning threads to CPUs to reduce jitter and latency. Lots of graphs and measurements from Peter Lawrey]]></description>
<dc:subject>pinning threads performance latency jitter tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:186b39854e95/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pinning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final77.pdf">
    <title>'Bobtail: Avoiding Long Tails in the Cloud' [pdf]</title>
    <dc:date>2014-02-27T15:15:06+00:00</dc:date>
    <link>https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final77.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A system that proactively detects and avoids bad neighbouring VMs without significantly penalizing node instantiation [in EC2].  With Bobtail, common [datacenter] communication patterns benefit from reductions of up to 40% in 99.9th percentile response times.'

Excellent stuff -- another conclusion they come to is that it's not the network's fault, it's the Xen hosts themselves.  The EC2 networking team will be happy about that ;)]]></description>
<dc:subject>networking ec2 bobtail latency long-tail xen performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a724de5104f3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bobtail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:long-tail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://latencyutils.github.io/LatencyUtils/">
    <title>LatencyUtils by giltene</title>
    <dc:date>2013-11-13T22:00:09+00:00</dc:date>
    <link>http://latencyutils.github.io/LatencyUtils/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The LatencyUtils package includes useful utilities for tracking latencies. Especially in common in-process recording scenarios, which can exhibit significant coordinated omission sensitivity without proper handling.</blockquote>

]]></description>
<dc:subject>gil-tene metrics java measurement coordinated-omission latency speed service-metrics open-source</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cee7964c8c45/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coordinated-omission"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cs.rutgers.edu/~muthu/bquant.pdf">
    <title>&quot;Effective Computation of Biased Quantiles over Data Streams&quot; [paper]</title>
    <dc:date>2013-11-01T16:57:06+00:00</dc:date>
    <link>http://www.cs.rutgers.edu/~muthu/bquant.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Skew is prevalent in many data sources such as IP traffic streams.To continually summarize the distribution of such data, a high-biased set of quantiles (e.g., 50th, 90th and 99th percentiles) with finer error guarantees at higher ranks (e.g., errors of 5, 1 and 0.1 percent, respectively) is more useful than uniformly distributed quantiles (e.g., 25th, 50th and 75th percentiles) with uniform error guarantees. In this paper, we address the following two prob-lems. First, can we compute quantiles with finer error guarantees for the higher ranks of the data distribution effectively, using less space and computation time than computing all quantiles uniformly at the finest error? Second, if specific quantiles and their error bounds are requested a priori, can the necessary space usage and computation time be reduced?  We answer both questions in the affirmative by formalizing them as the “high-biased” quantiles and the “targeted” quantiles problems, respectively, and presenting algorithms with provable guarantees, that perform significantly better than previously known solutions for these problems. We implemented our algorithms in the Gigascope data stream management system, and evaluated alternate approaches for maintaining the relevant summary structures.Our experimental results on real and synthetic IP data streams complement our theoretical analyses, and highlight the importance of lightweight, non-blocking implementations when maintaining summary structures over high-speed data streams.
<blockquote>

Implemented as a timer-histogram storage system in http://armon.github.io/statsite/ .]]></description>
<dc:subject>statistics quantiles percentiles stream-processing skew papers histograms latency algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:54346b7d58f0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stream-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:skew"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:histograms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://queue.acm.org/detail.cfm?id=2536492">
    <title>Barbarians at the Gateways - ACM Queue</title>
    <dc:date>2013-10-19T20:36:17+00:00</dc:date>
    <link>http://queue.acm.org/detail.cfm?id=2536492</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
I am a former high-frequency trader. For a few wonderful years I led a group of brilliant engineers and mathematicians, and together we traded in the electronic marketplaces and pushed systems to the edge of their capability.</blockquote>

Insane stuff -- FPGAs embedded in the network switches to shave off nanoseconds of latency.]]></description>
<dc:subject>low-latency hft via:nelson markets stock-trading latency fpgas networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:89014695d9aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:markets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stock-trading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fpgas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://chimera.labs.oreilly.com/books/1230000000545">
    <title>&quot;High Performance Browser Networking&quot;, by Ilya Grigorik, read online for free</title>
    <dc:date>2013-10-15T09:57:32+00:00</dc:date>
    <link>http://chimera.labs.oreilly.com/books/1230000000545</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Wow, this looks excellent.  A must-read for people working on systems with high-volume, low-latency phone-to-server communications -- and free!

<blockquote>How prepared are you to build fast and efficient web applications? This eloquent book provides what every web developer should know about the network, from fundamental limitations that affect performance to major innovations for building even more powerful browser applications—including HTTP 2.0 and XHR improvements, Server-Sent Events (SSE), WebSocket, and WebRTC.

Author Ilya Grigorik, a web performance engineer at Google, demonstrates performance optimization best practices for TCP, UDP, and TLS protocols, and explains unique wireless and mobile network optimization requirements. You’ll then dive into performance characteristics of technologies such as HTTP 2.0, client-side network scripting with XHR, real-time streaming with SSE and WebSocket, and P2P communication with WebRTC.

Deliver optimal TCP, UDP, and TLS performance;
Optimize network performance over 3G/4G mobile networks;
Develop fast and energy-efficient mobile applications;
Address bottlenecks in HTTP 1.x and other browser protocols;
Plan for and deliver the best HTTP 2.0 performance;
Enable efficient real-time streaming in the browser;
Create efficient peer-to-peer videoconferencing and low-latency applications with real-time WebRTC transports</blockquote>

Via Eoin Brazil.]]></description>
<dc:subject>book browser networking performance phones mobile 3g 4g hsdpa http udp tls ssl latency webrtc websockets ebooks via:eoin-brazil google http2 sse xhr ilya-grigorik</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5312bd9b166a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:book"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:4g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hsdpa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:webrtc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:websockets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebooks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:eoin-brazil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xhr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ilya-grigorik"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2">
    <title>Rapid read protection in Cassandra 2.0.2</title>
    <dc:date>2013-10-05T20:56:35+00:00</dc:date>
    <link>http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nifty new feature -- if a request takes over the 99th percentile for requests to that server, it'll be repeated against another replica.  Unnecessary for Voldemort, of course, which queries all replicas anyway!]]></description>
<dc:subject>cassandra nosql replication distcomp latency storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:74b80ef24320/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity">
    <title>Attacking Tor: how the NSA targets users' online anonymity</title>
    <dc:date>2013-10-04T16:31:54+00:00</dc:date>
    <link>http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>As part of the Turmoil system, the NSA places secret servers, codenamed Quantum, at key places on the internet backbone. This placement ensures that they can react faster than other websites can. By exploiting that speed difference, these servers can impersonate a visited website to the target before the legitimate website can respond, thereby tricking the target's browser to visit a Foxacid server.
</blockquote>

whoa, I missed this before.]]></description>
<dc:subject>nsa gchq packet-injection attacks security backbone http latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0a1aea658272/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gchq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-injection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:attacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backbone"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://attentionshard.wordpress.com/2013/09/30/why-tellybug-moved-from-cassandra-to-amazon-dynamodb/">
    <title>Why Tellybug moved from Cassandra to Amazon DynamoDB</title>
    <dc:date>2013-10-02T12:55:23+00:00</dc:date>
    <link>http://attentionshard.wordpress.com/2013/09/30/why-tellybug-moved-from-cassandra-to-amazon-dynamodb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Summary: poor reliability, better latencies, and cheaper (!)]]></description>
<dc:subject>aws dynamodb cassandra nosql storage tellybug counters scalability reliability latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8b0a38474b92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tellybug"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.meldium.com/home/2013/9/13/benchmarking-redis-on-aws-elasticache">
    <title>Benchmarking Redis on AWS ElastiCache</title>
    <dc:date>2013-09-16T22:48:55+00:00</dc:date>
    <link>http://blog.meldium.com/home/2013/9/13/benchmarking-redis-on-aws-elasticache</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good data points, but could do with latency percentiles]]></description>
<dc:subject>latency redis measurement benchmarks ec2 elasticache aws storage tests</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:19ca978874ad/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elasticache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tests"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://issues.apache.org/jira/browse/CASSANDRA-5582">
    <title>[#CASSANDRA-5582] Replace CustomHsHaServer with better optimized solution based on LMAX Disruptor</title>
    <dc:date>2013-09-03T22:29:45+00:00</dc:date>
    <link>https://issues.apache.org/jira/browse/CASSANDRA-5582</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Disruptor: decimating P99s since 2011]]></description>
<dc:subject>disruptor cassandra java p99 latency speed performance concurrency via:kellabyte</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:70d101c721e7/</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:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p99"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:kellabyte"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/mechanical-sympathy/icNZJejUHfE/BfDekfBEs_sJ">
    <title>Coordinated Omission</title>
    <dc:date>2013-08-05T22:00:16+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/mechanical-sympathy/icNZJejUHfE/BfDekfBEs_sJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Gil Tene raises an extremely good point about load testing, high-percentile response-time measurement, and behaviour when testing a system under load:

<blockquote>
I've been harping for a while now about a common measurement technique problem I call "Coordinated Omission" for a while, which can often render percentile data useless.  [...]  I believe that this problem occurs extremely frequently in test results, but it's usually hard to deduce it's existence purely from the final data reported. But every once in a while, I see test results where the data provided is enough to demonstrate the huge percentile-misreporting effect of Coordinated Omission based purely on the summary report.

I ran into just such a case in Attila's cool posting about log4j2's truly amazing performance, so I decided to avoid polluting his thread with an elongated discussion of how to compute 99.9%'ile data, and started this topic here. That thread should really be about how cool log4j2 is, and I'm certain that it really is cool, even after you correct the measurements.  [...] Basically, I think that the 99.99% observation computation is wrong, and demonstrably (using the data in the graph data posted) exhibits the classic "coordinated omission" measurement problem I've been preaching about. This test is not alone in exhibiting this, and there is nothing to be ashamed of when you find yourself making this mistake. I only figured it out after doing it myself many many times, and then I noticed that everyone else seems to also be doing it but most of them haven't yet figured it out. In fact, I run into this issue so often in percentile reporting and load testing that I'm starting to wonder if coordinated omission is there in 99.9% of  latency tests ;-)
</blockquote>]]></description>
<dc:subject>measurement testing latency load-testing gil-tene coordinated-omission validity log4j percentiles</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:36240fa70ac9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coordinated-omission"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:validity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:log4j"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.filepicker.io/post/29422604907/improved-https-performance-with-early-ssl-termination">
    <title>Improved HTTPS Performance with Early SSL Termination</title>
    <dc:date>2013-07-15T09:50:00+00:00</dc:date>
    <link>http://blog.filepicker.io/post/29422604907/improved-https-performance-with-early-ssl-termination</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a neat hack.  Since SSL/TLS connection establishment requires lots of consecutive round trips before the connection is ready, by performing that closer to the user and reusing an existing region-to-region connection behind the scenes, the overall latency is greatly improved.  Works for HTTP as well]]></description>
<dc:subject>http https ssl architecture aws ec2 performance latency internet round-trip nginx tls</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c5687e3aabe7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:https"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<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:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:round-trip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/sthair/measuring-mobile-web-performance-v2">
    <title>_Measuring Mobile Web Performance_ [slides]</title>
    <dc:date>2013-06-28T11:27:12+00:00</dc:date>
    <link>http://www.slideshare.net/sthair/measuring-mobile-web-performance-v2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Notable slide is #13, displaying a graph of HSDPA packet RTTs measured from a train.  Max RTT gets up to 20,266ms.  ouch]]></description>
<dc:subject>rtt packets latency hsdpa mobile internet trains packet-loss</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a63232d61e87/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rtt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hsdpa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trains"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-loss"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://netsekure.org/2010/03/tls-overhead/">
    <title>SSL/TLS overhead</title>
    <dc:date>2013-06-21T14:43:55+00:00</dc:date>
    <link>http://netsekure.org/2010/03/tls-overhead/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The TLS handshake has multiple variations, but let’s pick the most common one – anonymous client and authenticated server (the connections browsers use most of the time).'  Works out to 4 packets, in addition to the TCP handshake's 3, and about 6.5k bytes on average.]]></description>
<dc:subject>network tls ssl performance latency speed networking internet security packets tcp handshake</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9941807de694/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:handshake"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.bailis.org/blog/communication-costs-in-real-world-networks/">
    <title>Communication costs in real-world networks</title>
    <dc:date>2013-05-24T16:08:04+00:00</dc:date>
    <link>http://www.bailis.org/blog/communication-costs-in-real-world-networks/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Peter Bailis has generated some good real-world data about network performance and latency, measured using EC2 instances, between ec2 regions, between zones, and between hosts in a single AZ. good data (particularly as I was looking for this data in a public source not too long ago).

<blockquote>
I wasn’t aware of any datasets describing network behavior both within and across datacenters, so we launched m1.small Amazon EC2 instances in each of the eight geo-distributed “Regions,” across the three us-east “Availability Zones” (three co-located datacenters in Virginia), and within one datacenter (us-east-b). We measured RTTs between hosts for a week at a granularity of one ping per second.
</blockquote>

Some of the high-percentile measurements are undoubtedly impact of host and VM behaviour, but that is still good data for a typical service built in EC2.]]></description>
<dc:subject>networks performance measurements benchmarks ops ec2 networking internet az latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9dade9cdeb00/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurements"/>
	<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:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:az"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://developer.yahoo.com/blogs/ydn/posts/2013/02/storm-and-hadoop-convergence-of-big-data-and-low-latency-processing/">
    <title>Storm and Hadoop: Convergence of Big-Data and Low-Latency Processing</title>
    <dc:date>2013-02-28T09:57:37+00:00</dc:date>
    <link>http://developer.yahoo.com/blogs/ydn/posts/2013/02/storm-and-hadoop-convergence-of-big-data-and-low-latency-processing/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Yahoo! are going big with Storm for their next-generation internal cloud platform:

'Yahoo! engineering teams are developing technologies to enable Storm applications and Hadoop applications to be hosted on a single cluster.

• We have enhanced Storm to support Hadoop style security mechanism (including Kerberos authentication), and thus enable Storm applications authorized to access Hadoop datasets on HDFS and HBase.
• Storm is being integrated into Hadoop YARN for resource management. Storm-on-YARN enables Storm applications to utilize the computation resources in our tens of thousands of Hadoop computation nodes. YARN is used to launch Storm application master (Nimbus) on demand, and enables Nimbus to request resources for Storm application slaves (Supervisors).']]></description>
<dc:subject>yahoo yarn cloud-computing private-clouds big-data latency storm hadoop elastic-computing hbase</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:350773902d3f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yahoo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yarn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud-computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:private-clouds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:big-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elastic-computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hbase"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.altdevblogaday.com/2013/02/22/latency-mitigation-strategies/">
    <title>#AltDevBlogADay » Latency Mitigation Strategies</title>
    <dc:date>2013-02-22T17:55:55+00:00</dc:date>
    <link>http://www.altdevblogaday.com/2013/02/22/latency-mitigation-strategies/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[John Carmack on the low-latency coding techniques used to support head mounted display devices.

<blockquote>
Virtual reality (VR) is one of the most demanding human-in-the-loop applications from a latency standpoint.  The latency between the physical movement of a user’s head and updated photons from a head mounted display reaching their eyes is one of the most critical factors in providing a high quality experience.

Human sensory systems can detect very small relative delays in parts of the visual or, especially, audio fields, but when absolute delays are below approximately 20 milliseconds they are generally imperceptible.  Interactive 3D systems today typically have latencies that are several times that figure, but alternate configurations of the same hardware components can allow that target to be reached.

A discussion of the sources of latency throughout a system follows, along with techniques for reducing the latency in the processing done on the host system.
</blockquote>]]></description>
<dc:subject>head-mounted-display display ui latency vision coding john-carmack</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8f9b7e07fe99/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:head-mounted-display"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:display"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vision"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:john-carmack"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.anandtech.com/show/6432/the-intel-ssd-dc-s3700-intels-3rd-generation-controller-analyzed/3">
    <title>AnandTech - The Intel SSD DC S3700: Intel's 3rd Generation Controller Analyzed</title>
    <dc:date>2012-11-06T11:01:06+00:00</dc:date>
    <link>http://www.anandtech.com/show/6432/the-intel-ssd-dc-s3700-intels-3rd-generation-controller-analyzed/3</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting trend; Intel moved from a btree to an array-based data structure for their logical-block address indirection map, in order to reduce worst-case latencies (via Martin Thompson)]]></description>
<dc:subject>latency intel via:martin-thompson optimization speed p99 data-structures arrays btrees ssd hardware</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:04d3d7d3e082/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:intel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:martin-thompson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p99"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arrays"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:btrees"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
</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="http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html">
    <title>Overclocking SSL</title>
    <dc:date>2010-07-05T12:50:29+00:00</dc:date>
    <link>http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[techie details from Adam Langley on how Google's been improving TLS/SSL, with lots of good tips. they switched in January to HTTPS for all Gmail users by default, without any additional machines or hardware]]></description>
<dc:subject>certificates encryption google https latency speed ssl tcp tls web performance</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:52be96613038/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:certificates"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:https"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lists.canonical.org/pipermail/kragen-tol/2010-June/000917.html">
    <title>MapReduce as a way to cope with high-latency memory</title>
    <dc:date>2010-06-21T11:21:46+00:00</dc:date>
    <link>http://lists.canonical.org/pipermail/kragen-tol/2010-June/000917.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting thoughts from Kragen]]></description>
<dc:subject>kragen thoughts random mapreduce memory speed latency</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:e82fa500b315/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kragen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thoughts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:random"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mapreduce"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>