<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Latency on Micha Kops&#39; Tech Notes</title>
    <link>https://www.hascode.com/tags/latency/</link>
    <description>Recent content in Latency on Micha Kops&#39; Tech Notes</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>Copyright © 2010 - 2025 Micha Kops. #e9d956c0c0154a221ad83c925346a8fa0e72f866</copyright>
    <lastBuildDate>Sun, 30 Sep 2018 00:00:00 +0200</lastBuildDate>
    <atom:link href="https://www.hascode.com/tags/latency/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Capacity Planning using the Universal Scalability Law with Java and usl4j</title>
      <link>https://www.hascode.com/capacity-planning-using-the-universal-scalability-law-with-java-and-usl4j/</link>
      <pubDate>Sun, 30 Sep 2018 00:00:00 +0200</pubDate>
      <guid>https://www.hascode.com/capacity-planning-using-the-universal-scalability-law-with-java-and-usl4j/</guid>
      <description>&lt;div id=&#34;preamble&#34;&gt;
&lt;div class=&#34;sectionbody&#34;&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;Capacity planning is an important task when trying to anticipate resources and scaling factors for our applications.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;The usl4j library offers us an easy abstraction for Neil J. Gunther’s Universal Scalability Law and allows us to build up a predictive model based on the parameters throughput, latency and concurrent operations.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;With a basic input set of two of these parameters, we are able to predict how these values change if we change one input parameter so that we can build our infrastructure or systems according to our SLAs.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Testing Java Applications for Resilience by Simulating Network Problems with Toxiproxy, JUnit and the Docker Maven Plugin</title>
      <link>https://www.hascode.com/testing-java-applications-for-resilience-by-simulating-network-problems-with-toxiproxy-junit-and-the-docker-maven-plugin/</link>
      <pubDate>Sun, 29 Jul 2018 00:00:00 +0200</pubDate>
      <guid>https://www.hascode.com/testing-java-applications-for-resilience-by-simulating-network-problems-with-toxiproxy-junit-and-the-docker-maven-plugin/</guid>
      <description>&lt;div id=&#34;preamble&#34;&gt;
&lt;div class=&#34;sectionbody&#34;&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;When implementing distributed systems, client-server architectures and simple applications with network related functionalities, everything is fine when we’re in the development or in the testing stage because the network is reliable and the communicating systems are not as stressed as they are in production.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;But to sleep well we want to validate how resilient we have implemented our systems, how they behave when the network fails, the latency rises, the bandwidth is limited, connections time out and so on.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
    <item>
      <title>Observability Snippets</title>
      <link>https://www.hascode.com/observability-snippets/</link>
      <pubDate>Mon, 01 Mar 2010 00:00:00 +0100</pubDate>
      <guid>https://www.hascode.com/observability-snippets/</guid>
      <description>&lt;div class=&#34;sect1&#34;&gt;
&lt;h2 id=&#34;_the_use_methodology&#34;&gt;The USE Methodology&lt;/h2&gt;
&lt;div class=&#34;sectionbody&#34;&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;&lt;strong&gt;USE&lt;/strong&gt; stands for &lt;strong&gt;Utilization&lt;/strong&gt;, &lt;strong&gt;Saturation&lt;/strong&gt;, and &lt;strong&gt;Errors&lt;/strong&gt;. Developed by Brendan Gregg, it’s a low-level diagnostic tool for infrastructure and system resources.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;ulist&#34;&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;Utilization&lt;/strong&gt; – How much of a resource is used? (e.g., 70% CPU)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;Saturation&lt;/strong&gt; – Is the system over capacity? (e.g., CPU run queue)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;Errors&lt;/strong&gt; – Are there hardware or system faults? (e.g., disk errors)&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;&lt;strong&gt;Best for&lt;/strong&gt;: Bottleneck analysis on servers, network, disk, memory&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;Source: &lt;a href=&#34;https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/best-practices/&#34; class=&#34;bare&#34;&gt;https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/best-practices/&lt;/a&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class=&#34;sect1&#34;&gt;
&lt;h2 id=&#34;_the_red_methodology&#34;&gt;The RED Methodology&lt;/h2&gt;
&lt;div class=&#34;sectionbody&#34;&gt;
&lt;div class=&#34;paragraph&#34;&gt;
&lt;p&gt;&lt;strong&gt;RED&lt;/strong&gt; focuses on service-level performance and is tailored for microservices and HTTP-based systems.&lt;/p&gt;
&lt;/div&gt;</description>
    </item>
  </channel>
</rss>
