<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>benchmark on </title>
    <link>/tags/benchmark/</link>
    <description>Recent content in benchmark on </description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Sat, 18 Feb 2017 10:02:50 +0000</lastBuildDate><atom:link href="/tags/benchmark/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>HTTP load testing strategies and tools</title>
      <link>/http-load-testing-strategies-tools/</link>
      <pubDate>Sat, 18 Feb 2017 10:02:50 +0000</pubDate>
      
      <guid>/http-load-testing-strategies-tools/</guid>
      <description>&lt;p&gt;In most cases web applications are well covered with unit tests, to covert a functional requirements and acceptance tests. Unit tests combined with Continuous Integration can improve the deviling rate of a team/company. At the same time it can remove the need of manual testing, which is error prone. Tools for CI are widely available in self hosted solutions like Jenkins or cloud based like CircleCi or Travis, if the project source does not need to be secured as much. In any case these tools offer a wide variety of build and test scheduling to automated deployment and configuration. I think for most Software Engineers these are familiar concepts and possible part of daily work routines.&lt;/p&gt;
&lt;p&gt;One important part of most web based application is not covered with these tools, the benchmark or load test of new features and the application in general. It is obvious that CI tools are not meant for this task, but to have good understanding where the application bottlenecks and limitations are is crucial. In most cases this is an SRE or DevOps task clearly, but I think it is good for all Engineers to understand they changes and the consequences of them (if any). There is also another important factor which is the price of keeping one system up. Many times I heard, read that “…the application is not busy, so it does not matter…”. I believe that it does, even in not busy apps, because the development time/cost is a small percentage of the system all over lifetime cost. There is a really good breakdown of this idea in the &lt;a href=&#34;http://shop.oreilly.com/product/0636920041528.do&#34;&gt;Site Reliability Engineering – How Google Runs Production Systems&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;For a developer there are many tools to benchmark new features, in a standalone setup in most modern stacks. The tricky part I think is to being able to measure and understand the capabilities of an application as a whole. For this post I will stick to the HTTP load testing tools I found useful and use on regular bases.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
