I want to load test an enterprise server which is running 80 different SOAP webservices. All webservices need to be used at the same time. I want to register breaking point of the overall system.
I found some tools for testing a single webservice but not for all at the same time. Which tools can i use?
Our tool http://www.stresstimulus.com can test multiple Web services at the same time. For each web service, create a separate test case http://support.stresstimulus.com/display/doc40/Creating+Multiple+Test+Cases
To do so, issue a SOAP request and record it with StresStimulus proxy, or import a Fiddler .saz capture file.
By default, all test cases will have the same mix weight = 1, so load will be spread between them evenly. To customize the load distribution, adjust the mix weights. After that, you can ramp-up the load to reach a breaking point. You'll receive a separate performance report for each web service as well as consolidated report with response times, errors and other KPI.
Related
We have an application which is meant for Android, iOS and desktop all 3 and all 3 are consuming webservices.
What I would like to know is that, should we record scenarios from Android, iOS and desktop seperately and make script or we can just hit the web services using jmeter?
Well-behaved load test should represent application under test real-life usage as close as possible. If desktop, Android and iOS applications use the same endpoint and send the same requests in terms of parameters - it will be enough to come up with only one Thread Group holding request(s) representing the load.
If there are differences depending on the platform i.e. in request parameters, headers, cookies, etc. - it's better to go for different Thread Groups representing different users sitting on different platforms or consider using i.e. Throughput Controller to mimic real anticipated distribution of the requests basing on the source platform.
I've noticed that most architectures that acts as a web service client uses a proxy to communicate with the rest server? While it is possible to access a rest service without a proxy server, one example I've read is this where it uses a proxy server to communicate with its rest server are there any advantages of using a proxy to access a rest service?
Using a proxy is usually not necessary for small local application web services. It depends mostly on your server load (number of clients, frequency of requests), and on the network area where your services are accessed : back-office server-to-server, front-office LAN, WAN or on the whole internet).
The REST webservices are mostly online resources, identified in a unique way by an URL, and generally served in a classic HTTP way. From the client side, he does not know if the data he gets is static, dynamic or cached. He simply gets the data as if it's static.
On large scale applications, with the increase of clients, resources and web services requests, you need technical components to handle problematics like user balancing, usage tracking of your web services as your application evolves. You'll also want to deliver the best performance you can to the clients. This can be achieved efficiently with a proxy solution.
Advantages of NOT using a proxy:
Simplicity
Advantages of using a proxy-based solution:
Rewrite URLs from a single centralized entry point (instead of setting it heterogeneously on each server/app/ws configuration).
Track the usage of your webservices (globally)
Enhance performance capabilities (caching, balancing to dedicated servers)
Managing API versions (switching gobally /myAPI from /myAPI-V1 to /myAPI-V2 easily done, and go back fingers in the nose)
Modifying some API calls on-the-fly (compatibility between versions, do preliminary input data validation, or add technical information to calls).
Manage webservices security globally (control IPs, quota per user, etc).
Hope this answers your question.
Edit (in answer to comment)
The proxy can act as a cache. For frequently asked resources (REST services), it can serve the same response to several users. Your service will be called juste once, even if there is 100 requests on this resource.
But this depend on how your services are really used, so you need to track requests to know if caching is helpful or not in your case.
How many users do you have ?
How many web services ?
Whar kind of data/resources are served ?
How fast are your services (individually) ?
What is the network performance ? (LAN? WAN? Internet? Mobile?)
How many servers and applications serve your users ?
Do you encounter any network load problems ?
A proxy cannot "accelerate" your existing services, but it can enhance the way you serve the resources to your clients.
Do not use a proxy if you do not know if you need it. You must know what is your actual system architecture and what are the weaknesses and bottlenecks.
My server application is using embedded jetty as an http end point. It hosts several web applications with a bunch of jsp/servlets as well as several web services.
This application will eventually be deployed on the cloud but before that I'd like to make sure that this app measures the inflow and outflow (in bytes) coming through the jetty. I could probably make a global filter and count bytes somehow..
But is there a more intelligent way of doing this?
You should check for NetworkTrafficListener in Jetty 7 & 8, and how to use it in this test class.
I have a web service which performs the submission of a small amount of data. It provides a synchronous request response service for my clients. This is working well. I have a new requirement to also support the submission of a much larger amount of the same data; about 10,000 times more data volume. Naturally the larger data will be an asynchronous service for my clients.
The infrastructure I use for the small amount of data cannot support both types of service; the large volume submissions will kill the responsiveness of my small volume submissions.
What I would like to do is be flexible with my deployment and make life simple for the people developing the client software which submits the data. I have been looking for a standards based way to do this:
- client calls my data submission web service
- server determines the amount of data being submitted
- if data is too big the server responds to the client with a different uri. The uri is for client to do the submission i.e. Redirect the client to bigger infrastructure
- client calls the different uri and gets service
I've done some searching and the general response is that this isn't something that is done in web services. I don't understand why. This seems like a reasonable requirement that is probably also true for clustered server scenario's.
Does anyone know if there are standards which cover this? If not, is there a better way?
A subtlety in my case is that I want all the traffic to flow differently for the large submission so I can't simply front end my infrastructure with a web service content aware proxy server. I need to push the web service call to a totally different place; much like a HTTP redirect.
Any help is appreciated.
We are trying to design 6 web services, which will serve another client component. The client component requires data from the web service we are implementing.
Now, the problem is, there is not 1 Web Service we are implementing, there is one Web Service which the client component hits, this initiates a series (5 more) of Web Services which gather data from their respective data stores and finally provide the data back to the original Web Service, which then delivers the data back to the client component.
So, if the requested data becomes huge, then, this will be a serious problem for our internal communication channel.
So, what do you guys suggest? What can be done to avoid overloading of the communication channel between the internal Web Service and at the same time, also delivering the data to the client component.
Update 1
Using 5 WS, where, 1WS does not know about the others, except the next one is a business requirement. Actually, 5 companies "small services" are being integrated.
We use Java and Axis2
We've had a similar problem. Apart from trying to avoid it (eg for internal communication go direct to db instead of web service) you can mitigate it by at least not performing the 5 or so tasks in series. Make new threads to collect them all in parallel and process them at the end to reduce latency (except where they might contend for the same resource and bottle neck).
But before I'd do anything load test it and see if it is even an issue and get some baseline stats so you can see what improvement each change makes. Also sometimes you might be better off tweaking network settings or the actual network rather than trying to optimise the code - but again test and see.
Put all the data on a temporary compressed file and give back the ftp url of the file.
The client fetches the big data chunk uncompress it and reads it. (maybe some authentication mechanism for the ftp server)