Your scenario is,
5 Users hitting 5 URLs(samplers) simultaneously.
So what you need to do is, in your Test Plan, add 5 Thread Groups. In each Thread Group configure the number of Threads to 5 and Ramp Up to 0.
Now, add one HTTP Request sampler in each Thread Group. Configure each sampler according to the URL you want to test.
Add Listener(s) to your ...
Ideally if you amount of virtual users in 2x times you should get 2x times larger throughput. When your reach saturation point throughput will stop increasing and response time will be growing.
In general my expectation is that for breaking point you will have extremely high response times.
When the application breaks you should STOP getting proper ...
As per Once Only Controller documentation:
The Once Only Logic Controller tells JMeter to process the controller(s) inside it only once per Thread, and pass over any requests under it during further iterations through the test plan.
So each your Thread will execute Once Only Controller's children only once, no matter how many loops your thread group will ...
Web application has frontend and backend and "some features loading more long" may be caused by either slow rendering or slow backend response.
First of all go for your browser developer tools and see where the page spends the most time. At this stage you can also use frontend performance testing tools like Lighthouse
This way you will be able to ...
I would say that the more proper approach would be to segregate load for different functional areas and concentrate on the maximum number of historically concurrent users. Let me explain in ore details.
...application will need to support...
This is not a concrete statement. Since normally application provides a set of features which performance might or ...
If your application worked fine so far I don't think you will run into problems. If your calculation is correct and you will not have more than 7 concurrent users you don't have anything to worry about.
However you can consider a Stress Test excercise in order to determine your application boundaries and determine when (and why) it gonna break.
Come up ...
The first priority goes to the blocker issue as this is blocking the execution of the functional testing. Even though the requirement is for performance of the application but still we have to focus on functionality of the application.
Once the functionality of the application is fixed then focus on the speed test.
For particular your image Y axis stands for Swap (page) file usage in bytes depending on chosen metric which could be one of:
You can calculate percentage for swap file as used/total * 100. For other metrics you will need to play the same trick.
See How to Monitor Your Server Health & Performance During a JMeter Load ...
If are asking how to send a file via email then I'm not sure the "stakeholders" will need this report as if a person is not capable of accomplishing this simple activity I strongly doubt the load report is relevant
If you need to do it using JMeter - you can pack the folder with the dashboard report using OS Process Sampler and SMTP Sampler (it will be a ...
Given you are talking about everything from Hardware to SQL Server to Code, I'm assuming your performance issue is being observed at a high level. i.e. you have no idea what component(s) may be at fault.
Here are some ideas of approach when you're not sure where to look:
Recreate and Isolate - By this, I mean try to create the simplest reproduce case that ...
I always have used JMeter for Performance Testing. On this question, I think watching this tutorial may help you for client-side performance testing:
A full stack QA engineer should be skilled in testing Web apps, APIs, performance, Databases, and Mobile.
The common skills that are in-demand are:
Selenium(Java or C#): For web app
API Testing: Postman
DBtesting : DBUnit , Database Benchmark
Mobile: Testcomplete, Appium
These are not listed out from blue, but from the job ...
Looking into How bots work article it is quite enough to send normal HTTP POST requests using JMeter's HTTP Request sampler in order to simulate real users talking to the bot:
You should be even able to record the requests from your browser/application to the Bot Controller, you should be interested in the ones which have api/messages in their Path. The ...
You covered some possibilities, plus db queries can also be an area of focus. I'd recommend starting at the lowest level (code) and working up, so as to eliminate as many variables as possible at each step along the way. A code profiling tool will be your friend here, like ReSharper dotTrace (C# world), and it should help you identify hotspots rather ...
Normally the process of identifying the bottleneck includes the following checks:
Baseline OS health metrics (CPU, RAM, Network, Disk, etc.). Your application can respond slowly due to simple lack of resources and upgrading the hardware will eliminate the issue. See How to Monitor Your Server Health & Performance During a JMeter Load Test article for ...
You can use a load testing tool like Apache JMeter to simulate hundreds or thousands of users concurrently using your application.
You can use JMeter's HTTP(S) Test Script Recorder to capture the traffic from mobile devices to the backend server and replay it with increased number of virtual users.
See Load Testing Mobile Apps Made Easy guide for more ...
You need to consider a different structure of your test to make it behave like a real browser:
Open Login Page (HTTP Get Request)
Extract _csrf_token value from the response and save it into a JMeter Variable
Perform Login (HTTP Post request). At this stage you need to provide credentials and _csrf_token from the previous request.
See How to Load Test ...
You are doing something very weird. JMeter threads are totally independent and each thread has its own context, variables, cookies, etc.
If you have 1 thread - it will execute 8 requests in sequential order (upside down)
If you have 2 threads - each of 2 threads will execute 8 requests in sequential order
So I would recommend removing your ...
Value of 70 in Error % means that 70% of samplers with that label have failed. If you don't have any assertions most probably there is HTTP Status Code >= 400 for this particular request(s)
If you expect status code 200 OK and response has different status equal or above 400 - JMeter automatically marks the request as failed and stores response message in ....
Try using Constant Throughput Timer
If you need to test your system at 3500 requests per second you need to use slightly different approach, to wit add Constant Throughput Timer to your Test Plan and configure it to limit JMeter requests rate
However from what I can see from your Summary Report the majority of samplers are executed at rate of 3 requests per ...
Load testing of the AJAX request is not easy and at the same time if we just record and play the same scenario won't work sometimes.
You have to use correlation in order to extract a particular parameter from the earlier request, for example like the - sessionid or the tokenid and then it needs to be passed to the next request so that they will work.
Using Selenium for just downloading a file is a little bit overkill as normally people go for Selenium and JMeter integration via WebDriver Sampler to test client-side performance while the system is under the load.
In order to test 500 users you will need to kick off 500 browsers therefore 10 VMs might be not enough (it depends on hardware specifications) ...
Please use setupThread group to prepare the test environment say test data configuration or like wise that needs to be executed only once before the testing actually begins.
If all you have is month-to-month estimates of how much work is going to be done, you absolutely can't then extrapolate down. If you had day-to-day numbers, I might be OK with using those, but within a month, a lot can happen. If you're building a system for a company in Europe or China, for example, it's entirely possible that 3/4 of the office will be ...
My expectation is that you don't need to test Kafka itself, you should run the same test as you had for the previous implementation and focus on real life application usage rather than on underlying transport. If everything goes well you should have either the same or better result.
If you will have worse result - it will indicate performance regression ...