I am using open source Gatling to test a non-http application. The execution of the test includes steps with very high response times (it is not an issue is the operation of this application) and when we trying to introduce more concurrent users, we always see that there is a limitation due to the number of cores of the injector and we cannot reach these desired concurrency values, (x2 parallel request per core is the limit, we have tested it with different processors).
We have seen that Gatling uses Akka for this management and we find this configuration file gatling/gatling-akka-defaults.conf at main · gatling/gatling · GitHub which allows to configure the number of threads per core.
We have tried to override these default values adding a src/test/resources/gatling-akka.conf file to our project with content similar to this, but we see that it is not working.
type = Dispatcher
executor = “thread-pool-executor”
parallelism-min = 20
parallelism-factor = 5.0
parallelism-max = 50
throughput = 100
I’m sure you don’t like us doing this kind of thing, but in this scenario, with such high response times, we cannot reach the concurrency defined in the scenario setup and we don’t see any other way to increase it.
Do we have any option?.
Thanks and best regards
I’m pretty sure that the threads amount is not the issue here.
The issue is the thread of the virtual user is kept running during your step.
“non-http” is your choice, and we have other protocols as well (websocket, and currently re-implemeting grpc, etc.). For my curiosity: if not HTTP, what is your protocol?
I think the issue is about blocking IO you use with your own protocol. Did you try non blocking client?
We have seen that Gatling uses Akka for this management
Making things clear: Akka usage in Gatling is very limited to some specific coordination components. Gatling virtual users don’t run on Akka threads.
Hello @sbrevet ,
Many thanks for your response.
My application under test creates and manages files, I have tried to build a new custom protocol but it is not easy for me, I am new with Gatling and I have not found much documentation on this.
Now I am using the http protocol but without sense, I connect with an ip:port and then execute the steps.
As you commented in your message, How could I not keep the vuser running when I execute the step, in order to get more concurrency?.
Thanks and best regards.
Try to look about non blocking io for your protocol. (as I don’t still know which protocol you use, I cannot help you about that)
Why do you connect to an ip:port at all if you don’t use HTTP? How do you manage your response time?
Thanks for your response @sbrevet.
I get the response time in the application log, it is not an important value on the client side.
I connect to an ip:port because I haven’t been able to build a protocol from scratch and Gatling needs a protocol to work. In this case, I don’t care about connecting to a dummy ip:port or putting “hello world”. I have included the construction of the requests and the calls to the application in the steps.
Where can I find documentation about non blocking io protocol?
For instance: nio
About creating a protocol in gatling, there is no documentation at the moment. You will have to dig in the code and in the internal of gatling to understand how it’s working. It’s a pretty hard work (for now).
I will review the documentation and I will try to solve the concurrency issue associated with the number of load injector cores.