CODEWITHSUNDEEP
multithreadingjmeterperformance-testing
karthick
karthick

Reputation: 1

Can the concurrent users requirement for front end application and backend application can be same?

I am testing an application (backend, which has few API's exposed). The TPS is met, response time is met. However, the test fails, started giving errors, when I Increase the threads (in Jmeter). (I am reading Threads as concurrent users) So, we have now been said that my application is the bottleneck. The requirement is 1000 concurrent users for the front end application. The user journey for 1 transaction in front-end application will be around 2 to 3 minutes.However, the application which I am testing is a stateless one (backend) and it responds in milli seconds and required TPS is met with 50 threads itself. But I am asked to test with 1000 threads for my application as well as the front end application has that requirement. Are they right in saying that? Can the requirement of 1000 concurrent users for a front-end application can be applied to the back-end application as well.

Upvotes: 0

Views: 649

Answers (2)

user2023577
user2023577

Reputation: 2111

If you had even a trivial tomcat without NIO, the only way the frontend would know that you don't support enough concurrent users is by the serversocket TCP syn queue being too short. (client getting TCP RST)

Both jetty and tomcat have setting to make that serversocket queue longer. This is the easiest way to shut up anyone somehow detecting a limit in concurrent requests.

For example, you can "serve" 30 threads and connections only, but still have 1000 TCP SYN pending in the serversocket accept queue. This means connections are queued, thus accepted and as far as the client can judge, concurrent. They just happen to have a suspiciously longer E2E time because of the delay in this queue before being served.

Not matter what the backend will be, at some point these 1000 requests will NOT be concurrent: perhaps they funnel into 4 threads in a cassandra connection, or into 1 thread in some big lock in front of a poor bean validation cache, etc...

By queuing, you preserve control of the concurency to remain in a sweetspot of performance, and any excess requests translate progressively into more E2E time to traverse the queue and get serviced.

So, yes, they can request that you be able to accept 1000 requests, but they cannot know how the time is broken down.

Upvotes: 0

Dmitri T
Dmitri T

Reputation: 168082

Front-end is a web representation of the backend, isn't it? So frontend cannot work without the backend.

Normally product owner who is providing business non-functional requirements doesn't care at the slightest about underlying implementation (frontend, backend, databases, load balancers, etc.) so the requirement of 1000 concurrent users is applicable to the whole integrated system.

Now your goal is to identify the bottleneck, normally the process looks as follows:

  • Set up monitoring of baseline performance counters on the application under test side (CPU, RAM, Swap, network, disk, etc.). You can use JMeter PerfMon Plugin for this.
  • Start your test with 1 virtual user and gradually increase the load unless response time exceeds acceptable threshold or errors start occurring (whatever comes the first)
  • Check if lack of resources (CPU, RAM, etc.) could be the cause. If yes - you just need to migrate to more powerful server or scale application or optimize it. If no - check your application infrastructure (settings of web server, database server, etc.) as it might be the case that it is not suitable for higher loads.
  • It might also be the case your application code itself is the bottleneck. In this case use profiling tools to identify the slowest functions, largest objects, longest DB queries, etc.

Upvotes: 0

Related Questions