I need to stress test a Server with around 3000 users conecting to it concurrently via SyncML Clients. For simulation of each user, a application needs to be launched which then connects to the server and does some operations.
Each user corresponds to each process.
The process is unix based and does http transactions based on SyncML Protocol.
I need to run the load for these 3000 processes for an hour or so.
Can you suggest best industry methods to fulfil such requirements?
Can JMeter or Locust help me in this?
Regards
You can definitely use Locust for this.
I wouldn't recommend starting processes to generate the load (even though it's possible), mainly because you won't get detailed statistics on what requests are made, how long they take to complete, etc.
Either you could just manually do the HTTP POST requests containing the SyncML data with the built in Locust HTTP client, or you could actually take something like pysyncml, and make your own SyncML client that reports the requests it does to Locust. It's fairly simple to do, you can read more about it, and see example, on the documentation page about custom clients.
Yes, JMeter can do this, though it's not clear to me what exactly the unix based processes needs to do.
JMeter can natively make HTTP POST requests and send XML data. Unless you have some very custom logic to make the requests, stick to JMeter on it's own.
If you must, you CAN execute a local process, but then you're severely limiting the number of users you can simulate per machine.
http://jmeter.apache.org/usermanual/component_reference.html#OS_Process_Sampler
Related
Jmeter log replay taking more time .. can we able to use access log sampler in multiple thread? if so how to share the log files to all the threads?
Please help.
You can convert your access log into a CSV file with a script and use CSV Data Set Config in conjunction with the HTTP Request samplers - this way you will get it replayed with the multiple threads. See Stop Making Assumptions! Learn How to Replay Your Production Traffic With JMeter article to get the idea in more details and see the example implementation.
However be aware that this way most likely you won't be able to replay complex end-to-end scenarios, only simple HTTP GET requests which are not authenticated can be replayed this way. For quick-and-dirty test plan it might be enough, however it is much better to come up with modular test plan, reusable components, full control of workload, etc. so I would rather recommend building a web test plan from scratch.
I wonder if some one solved the issue of browser multi thread with a request response script for load test
If you are going to use real Chrome and FF browsers for load test you can consider the following options:
Selenium Grid
Selenium-Grid allows you run your tests on different machines against different browsers in parallel. That is, running multiple tests at the same time against different machines running different browsers and operating systems. Essentially, Selenium-Grid support distributed test execution. It allows for running your tests in a distributed test execution environment.
Apache JMeter with the WebDriver Sampler plugin. This way you will be able to control concurrency and get performance metrics in form of HTML Reporting Dashboard.
Simulating web browser concurrency is something most load testing tools do very badly, if at all. We have tried to do this in k6 by letting each VU (virtual user) use multiple, concurrent TCP connections to fetch things in parallel. There is a special API function - http.batch() - that enables this functionality. http.batch() accepts multiple URLs as input parameters, and will fetch as many as possible in parallel.
Like Dmitri writes, Jmeter has a plugin that provides concurrency - sort of. However, what it actually does (unless I'm misinformed) is to spread out requests over multple VUs. Each VU will still only use one concurrent connection, which means that if you e.g. want to simulate 100 real browser users, you may need to fire up 1,000 VUs to do so realistically. This is not very different from what you would get with any other load testing tool, in my opinion: all of them allow you to start more VUs to create more concurrency and more traffic.
I'd say that apart from k6 and maybe one or perhaps two other tools (and Jmeter is not one of them), your only option if you want to really simulate the way browsers behave, is to use Selenium Grid or something similar to fire up a large number of real, actual browsers to do the load testing. The drawback is that real browsers are very expensive to run: they want lots of CPU and memory. But they provide the by far best browser "simulation".
I am using jMeter to load test logging in and logging out of my application. I have a CSV with 500 uname and pwords, and I have also set the active threads to 500.
Is this the correct way to stimulate a load of 500 users?
From technical perspective - yes, JMeter will pick up credentials from CSV and send them along with the request.
However if you think about what happens in reality logging in and immediately logging out doesn't seem a realistic use case for me. The whole idea of load testing a web application is simulating real users as close as possible, it includes:
Application usage scenario(s): how many users will be accessing your application at the same time and what users will be doing what things? For example given Stack OverFlow the vast majority of users are searching for answers by given criteria, some users are typing questions, some of them providing answers, and some of them are commenting. These all are different behavioral patterns which need to be accurately simulated by your load test
Each user should have a "user session" which identifies him so application would distinguish different users so make sure you have HTTP Cookie Manager in your Test Plan
Real users use real browsers which are downloading images, CSS and JavaScript files using parallel thread pool (around 5 concurrent threads) to speed up page loading process. In order to mimic this behavior you need to configure HTTP Request samplers to download embedded resources and do it in parallel. You can apply this configuration to all the HTTP Request samplers via HTTP Request Defaults.
Don't forget to add HTTP Cache Manager to mimic browser cache as real browsers normally cache embedded resources to disk and don't re-request them on subsequent calls.
So I would recommend reviewing your test scenario and/or load pattern and get familiarized with How to make JMeter behave more like a real browser article
I'm planning to do a load test of our ASP/.NET web application and need to simulate about 600 concurrent users on our system.
Initially we'll just be running the load test tools (probabaly JMETER or WCAT/WAST) from our personal workstations which are Windows 7/32 Bit Dells (Dual Core processors). I was wondering about how many users I can expect to be able to simulate from one client.
If I can easily do 200 users per client, I'll need to identify 2-3 more clients for the test.
I wanted to ask the community based on their experience how many users I should expect per client on a standard windows box.
Any help is appreciated!
This highly depends on the test plan itself and cannot be answered that easily.
If you for example have 500 users that just do one request and then have a waiting timer for five minutes, this should work. If all users constantly do requests without waiting, this will put much more load on your machine.
It depends on the samplers in use. HTTP requests are less costly than SOAP requests for example.
It also depends on the listeners you have active.
For a normal load test I usually have around 100-300 threads active. I would suggest to start with such a number and to monitor the load (CPU, network) on your client to see how much potential there is.
Without more details about the test scenarios and the hardware, it is hard to give specific answers. But our Load Tester product can (usually) handle this level of users pretty easily on a single machine (assuming relatively modern hardware). The testing tool should scale linearly up to a point, so you should be able to get a good estimate by running 50 users through a scenario that is similar to what you expect to test.
Which tools can be used to measure performance of a webserver?
To test a webserver, you can use Apache Jmeter.
To see where is the bottleneck you have to flood your server application.
ApacheBench (ab) can do this. Here is a tool to get the server HTTP response code (ab) just says there is an HTTP error, and to automate test runs:
dsec.com/source/ab.c.txt
This program also gives useful tips about how to configure Linux and Windows (TCP/IP system options) to get the best possible performances.
It always depends on the setup.
Depending on the application there can be different bottlenecks.
Sometimes its the CPU, sometimtes the database connections, sometimes the sockets, sometimes the hard disc etc...
Most common practice is to use siege (simple command line tool) and increase the concurrent connections and see how many transactions per second go through.
It will increase per connection until an optimum is reached, then it will slowly decrase.
You can produce a set of urls that are randomly accessed, maby biased and/or send random data, request random ids etc to simulate more "real" clients.
Completely depends on your application whether this is relevant.