FastHttpUser vs HttpUser difference

[Paladond]

Hi there!

I encountered the fact that with the same number of requests per minute that I generate using HttpUser and FastHttpUser - I get different response times.
HttpUser has a uniform graph of response times without "high jumps", the FastHttpUser "high jumps up" with a certain periodicity.

I don't understand the difference between them and how they work 😞

[cyberw]

Hi!

HttpUser uses python-requests, a pure python http client.

FastHttpUser uses geventhttpclient, which is a high performance http client based on an http parser written in C (llhttp).

FastHttpUser is faster in the sense that it uses less CPU resources on the load generator, but under normal circumstances (load generator not running out of any resources) there shouldn't be any big differences.

Its hard to say what might be causing the jumps you are seeing. There could be some minor differences in the requests sent by the different clients that makes a difference in your particular case. Maybe investigate the payload to see if there is any difference. https://docs.locust.io/en/stable/running-in-debugger.html#print-http-communication

[Paladond]

@cyberw , Could you show an option on how to use users so that each new request goes as a FastHttpUser or FastHttpSession for a more realistic simulation of connecting new browsers? I tried using FastHttpSession and calling the some "close" methods. But in this case I get the same type of "peaks" in the same time intervals.
I tried commenting out different "clear/close" lines to try all the options - but I always get "peaks" in the same place with the same response time.

session = FastHttpSession(self.client.environment, 
                          self.client.environment.host, 
                          user=self.user)
session.cookiejar.clear()
session.cookiejar.clear_session_cookies()
session.client.close()
session.client.clientpool.close()

self.client.client.close()

[cyberw]

Its a little hard to tell what is causing this. Could be throttling on server side or load gen/OS side (the TCP stack doesn't like processes opening lots of ephemeral ports).

Or are you saying you get peaks even when using the built in session object without calling any .close()?

[Paladond]

Its a little hard to tell what is causing this. Could be throttling on server side or load gen/OS side (the TCP stack doesn't like processes opening lots of ephemeral ports).

Or are you saying you get peaks even when using the built in session object without calling any .close()?

@cyberw , I get the same results without using the any ".close()" method.

And these are the results [attached screenshot] I get when I use the HttpUser. But in this case I'm not sure that I can test the server when I increase the load x2, x3 and more times. Because HttpUser uses a lot of resources and the error "Connection pool is full, discarding connection" can often occur.

[cyberw]

Oh, and btw, there's some docs about this: https://docs.locust.io/en/stable/writing-a-locustfile.html#connection-reuse

[cyberw]

Connection pool is full, discarding connection

Are you creating Fast/HttpSession's yourself? Don't do that unless you have some very good reason to... Every User has their own session, use that one.

[Paladond]

Connection pool is full, discarding connection

Are you creating Fast/HttpSession's yourself? Don't do that unless you have some very good reason to... Every User has their own session, use that one.

@cyberw , this is an example of my code:

def requests_generator():
    """ 
    Count requests per minute.
    """
    requests_data = [
        (10, 6.0), (5, 12.0), (6, 10.0), (5, 12.0), (20, 3.0), (6, 10.0), (11, 5.45), (5, 12.0), (10, 6.0),
        (17, 3.53), (29, 2.07), (10, 6.0), ...
        ]
    return requests_data

class CustomUserTaskSet(TaskSet):
    requests_list = requests_generator()

    @task
    def first_task(self):
        group = Group()

        for request_counts, sleep_time in self.requests_list:
            for _ in range(request_counts)
                group.spawn(self.apply3d)
                gevent.sleep(sleep_time)

    def apply3d(self):
        session = FastHttpSession(self.client.environment,
                                  self.client.environment.host,
                                  user=self.user)
        session.request("POST", "ENDPOINT", json="json_data", headers="headers")


class CustomUser(FastHttpUser):
    tasks = [CustomUserTaskSet]

[cyberw]

Don't create your own session. Just use self.client instead. Creating lots of sessions will overload your OS/TCP stack. If you want to do concurrent requests within the same User, follow the instructions in the docs: https://docs.locust.io/en/stable/increase-performance.html#concurrency

[Paladond]

Yes, I monitored the logs on the server for both FastHttpUser and HttpUser. The execution time on the server according to the logs is the same for FastHttpUser and HttpUser. But the FastHttpUser graph is completely different from HttpUser.

All payloads, headers, etc. are actual.

[cyberw]

And there's nothing in the locust logs? Is it the same issue if you run distributed using more load generators? If you're doing high load maybe it is an OS/TCP stack-related issue..

[Paladond]

And there's nothing in the locust logs?

At least there are no errors or anything like that in the Locust logs.

Is it the same issue if you run distributed using more load generators?

I don't want to run distributed at this stage of my tests.

If you're doing high load maybe it is an OS/TCP stack-related issue..

But I do the same load changing only FastHttpUser or HttpUser class.

I have a thought in my head that if I generate the same number of requests per minute, then I should see the same result for FastHttpUser and HttpUser.

[cyberw]

Yes you should see the same results, but if your OS/TCP stack is overburdened then all bets are off. What kind of throughput/user count are you doing?

[Paladond]

I use only the one user to generate all requests because I want to control the number of requests per minute.
I mean I spawn 1 user when I run the locust test.