Project Performance Test

    Often our task is to test the load the site of our customers can withstand . For ourselves, as a testing tool, we chose yandex-tank. This will be a brief note on how to quickly start working with this tool.

    And so, in order. We put the yandex tank on CentOS 7. I must say right away on the 6th it did not start, but on 7 it started with a bang. To put it:
    yum install libxml2-devel libxslt1-devel python-devel zlib1g-devel python-pip
    pip install --upgrade pip  
    yum groupinstall 'Development Tools'
    pip install yandextank  

    After performing these simple actions, we got the working core of the tank. But we still need to put a query generator. As a generator, we chose phantom, you can also use jmetr and others. To install phantoma, just do the following:
    yum install perl openssl-devel binutils-devel make git -y
    git clone
    cd phantom
    make -R all
    mv ./bin/phantom /usr/bin/
    mv ./lib/phantom/ /usr/lib/

    Almost everything is ready for use, it remains only to prepare the file with the test configuration, with us it looks something like this:

    time_periods  = 1ms 2 3 4 5 6 7 8 9 10 20 30 40 50 60 70 80 90 100 150 200 250 300 350 400 450 500 600 650 700 750 800 850 900 950 1s 1500 2s 2500 3s 3500 4s 4500 5s 5500 6s 6500 7s 7500 8s 8500 9s 9500 10s 11s 12s 13s 14s 15s 16s 17s 18s 19s 20s 21s 22s 23s 24s 25s 26s 28s 29s 30s 100s 300s
    port = 80 ;
    interval = 1 ;
    manualstop = 1 ;
    address =
    ;ssl = 1
    port = 80
    rps_schedule=step(10,100,10, 10s) ;load schemei
    ; Headers and URIs for GET requests
    header_http = 1.1
    headers = [Host:]
    ;    [Authorization: Basic xxxxxxxxxxxxxx]
        [Connection: close]
    uris =  /

    Now a little about what all of this means:

    1. [loadosophia] is a section that describes where to add reports. To configure it, you need to register on , generate a token there and specify it in the configuration file.
    It is also convenient to specify test_title so that when testing multiple sites it is possible to separate reports.

    2. [aggregator] intervals for rounding the results, list separators - spaces

    3. [web] module launches a local web server showing online test charts.

    4. [phantom]

    address - the address of the server on which the site is located. It can be set both in the form of iP and
    ssl URL - whether ssl is used, 1 - yes, 0 - no
    port - site port
    rps_schedule the most interesting, it shows how the load will be applied. and here 3 options are possible:

    step (start rps, stop rps, step, time)
    start rps - how many rps to start.
    stop rps - how many rps do the test do.
    step - how many rps to add.
    time - time of each step.

    Constant load:

    const (rps, time)

    line (star rps, stop rps, time)
    Example: step (10.50, 3, 60s) - in this case, the test starts at 10 rps, and every 60 seconds will add 3 rps until it reaches 50 rps.

    headers - headers transmitted with the request.
    Example: [Host:] so that you can determine which vhost;
    [Authorization: Basic dmd1cnlhbm92Ok1pbGVuaXVtMzIx] - if authorization is needed;
    [Connection: close] - so that the server closes the connection immediately, and not by timeout.

    uris - a list of uri on which the

    ammofile test will go - instead of uris, the name of the file containing the list of requests is set.

    instances - the maximum number of testing threads /

    5. [autostop] section in which it is determined in which case to stop testing.

    time - stop the test if the average response time exceeds a specified threshold for a given time, exit code 21. For example: time (1s500ms, 30s) time (50.15)
    http - stop the test, if the number of HTTP codes corresponding to the mask is greater than the specified absolute or relative threshold, the exit code is 22. Examples: http (404,10,15) http (5xx, 10%, 1m)
    net - similar to HTTP codes, but for network response codes, the exit code is 23. An xx mask is allowed, meaning "all non-zero"

    Well, a little about how the reports look:

    Summary tab: general test data.
    Distributions tab: Contains data on the distribution of response time to the request. Simply put, how many requests were received over a period of time n:
    Number of responses in 0-100,100-200 ms, etc.
    What% of responses were received in time n:

    Timelines tab: Distribution of response time depending on the response.

    Important indicators:
    TPS (transaction per sec) is the same as rps.
    VU how many parallel processes were running to provide a given number of rps.
    TPS = (1000 / responce time) * VU.

    The most interesting graph:
    Average response time for a given number of rps

    Target Monitoring tab:
    Here you can see the parameters of the tested network, if an agent is installed on it. It is installed automatically by ssh.
    The remaining tabs are a variation.

    And finally, for those who have read to the end) I’ll tell you how we use it. Usually, at the beginning we enable all kinds of logging on the server, and run a quick test with unlimited rps (~ 10000). We look how much the server withstands and we remember this number. Then comes the process of optimizing the server, viewing logs, searching for slow queries in the database and slow php scripts, with optimization of system settings. And so on until, until we see that the servers are no longer held due to resources. We conduct a test, compare the resulting figure with the original and rejoice. Well, in the end, we run the test for several hours to make sure that the site can withstand a long load.

    In one of the following articles we will try to show how the optimization is going on as an example.

    Posted by: company system administrator Magvai69

    Also popular now: