I'd like to use JMeter to test an asynchronous web service. Namely, JMeter is used to send Soap requests to a webservice (invoking some WSDL defined routines) and the webservice will queue these operations for later execution. It will respond with a notification for each operation that is executed.
I would like to be able to track the latency between request and response for each request sent.
Since the request and response happen asynchronously, I would need a way of mapping each request that I send to the response which may come back later.
Can someone point me to the simplest way of doing this in JMeter?
Thanks in advance.
the simplest way I see is to setup a thread simulating each user.
After sending the request, the thread polls for the response, which is the way a browser would work.
Obviously, this cannot be done when the time between request and response is long, and/or volumes become very large. In this case, you probably would need to log each event and to calculate time duration offline.
Related
There is a client to my server, which is calling a GET API to know all updates regarding a particular thing very frequently (let's say once every 5 seconds). Due to this there is unnecessary network calls are landing on my server even if I don't an an update to share.
I reached a decision to replace above approach with web-hooks, where I'll call there POST API whenever I have an Update to share instead of letting them put unnecessary load on my server.
What I understand about Web-hooks:
A web-hook is like a reverse API which POSTs the updates to the server (The client which was calling our application frequently to know/GET updates).
My client has to implement a Web-hook client, which is basically a POST API, I'll be calling whenever there's an event/update to be shared.
I need to call their POST API using REST template wherever there's a new event.
What I don't understand:
Is there anything called a Webhook server? If yes, how do I create/implement it? Any references?
Is it just a reverse API, or is there anything special which both the server and the client needs to handle?
Webhooks are usually used to notify other service that some event occurred on your side. This is made by standard HTTP request sent to some URL.
There is no specific thing like Webhook Server. This is standard application that sends request to someone proactively.
Should both services communicating with webhooks handle something special - this depends on your architecture, there is no "standard" here. You can implement any sort of retry or mechanism to validate that the other side received the information. Im most cases it is assumed that webhooks should be idempotent, so if two same webhooks are sent, the other side should not repeat their action.
I am planning to create a rest API that receives a HTTP request from UI. this rest api needs to trigger a task which may takes more than 1 hour and we don't want UI waiting for this response. if the request is reached to server, we just want to send the response back with status=ok and let the task on server side goes on. once the task is completed, it will update DB with status=success. when fails, will update DB with status=fail. so that a user can check the status of task on UI that pulled from this table later.
I am thinking of adding the request into DB table and check that table with cron scheduler(1 min interval) to see if there is any request in and process. However, if there is other better solution, I would like to try. Please, let me know if there is other options(some hints). I will google further!
Thanks!
From the REST API standpoint you have the option of asynchronous calls with polling, or pushing updates to the UI.
For Polling these are the steps:
Client sends HTTP request and gets an HTTP 202 response plus a location URL for checking statuses.
Client can continue sending requests to the check status URL which will return 202 as long as the result is pending.
Once the work is done, a client request to the check status URL will then return HTTP 302 along with the URL of the final resource for the client to access.
Here's more info on the asynchronous REST API pattern with polling: https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply
If you prefer pushing results to the client then you can look into WebSockets as was recommended by another user. WebSockets has obvious advantages but would require support for the websockets framework in both UI and Server (it's a fairly well established framework so this shouldn't be a problem). Polling on the other hand would just be plain old HTTP.
I am not looking specific answer, just an idea or a tip.
I have following problem:
Android application is a client for web service. It has a thread, which sends events (XML form with request ID) through http protocol and for every request server sends confirmation, that he understand message right with granted event ID - server is a synchronizer for few clients. I want use websocket protocol to send events through websocket too but it is a little bit tricky - instead of http, I don't expect to get response for every request. Moreover, incoming websocket messages is parsed in other thread. Primary mechanism it's a little bit overgrown and I don't want to write everything from scratch.
I want to make this asynchronous websocket mechanism to pretend to be synchronous.
There is my idea for now - after send event through websocket I will wait no more for e.g 5 seconds for response which will processed in other thread (it's came as XML) and regarding too request ID it will notify proper paused thread. I worry Condition.await() and condition.signal isn't the best idea, what do you think?
According to this problem, I've realized that I have problems with project this kind of mechanism. Do you have an idea, where can I find information about good pattern and tips which good to now to avoid bad approach? Thanks in advance!
The only difference between websocket and HTTP requests is the lack of HTTP headers when a message comes in. In websocket, you have a heartbeat that keeps the connection alive and allows full duplex communication, and then you have pure payloads. It's your job to find which message headers you will use to route the requests properly in your server/client.
So, that doesn't stop you from communicating in a request/response manner by simply writing to the output stream right after receiving. I suggest you take a look at the RFC
https://www.rfc-editor.org/rfc/rfc6455
If you're a little more visual, this slideshow can help:
http://www.slideshare.net/sergialmar/websockets-with-spring-4
Or if you want some more serious implementations as an example, take a look at spring's docs:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html
For a web service application, I would like for the server to be able to notify the clients about some events. When a client is launched, he calls one of the WS methods to get some information it needs. Then the server, that stores this information, listens continuously for changes on these information and if there is a change, it notifies the concerned client.
I don't know if a web service is a good solution to my problem? I don't know how it may work concerning the TCP connections, since the server may notify a client after a very long time.
What would be the best architecture to solve this kind of issue?
Thanks
EDIT: I've looked at some discussions that propose to use Comet, but if you think there are simpler and more convenient solution, please let me know. Since I'm starting this project from scratch, I have no limitations.
I can also use a polling model where the clients periodically poll the server for the information they need, but then I need to take into account the load that this model may create on the server. I don't know if web services can support such a load when there are a lot of clients.
I've also looked at the asynchronous functionality provided by Servlet 3.0 but I don't know how it may solve my problem.
Without polling: sockets
With polling and webservices: u should use etag (html).
When a client polls he sends a request with an etag. webservice responds either with 200(ok) and data or 304(not modified). 304 has no body => less trafic
Instead of client polling the server, you could implement a callback method on the client so that when ever server want to publish some changes to the client, the server can use the callback method provided by the client.
I can think of one the two approaches below using web services solution:
Callback: When client invokes the server it leaves its call back url and a id, say correlation id. When the server wants to respond back to the client it will just use the call back url to notify. The Server can use a variety of approaches to process the request asynchronously. Your client need not be a webservice for this, but it should be capable of accepting requests (callback). It can be a servlet etc.
Polling: When client makes a request to the server it receives back a id, say requestid. After specified interval client polls the server with this request id to fetch a response. A reasonable timeout and polling interval based on the processing time would be required.
Is there any way to locate a previous HttpRequest, for a given session?
Web client sends request to a long running web service. While this service is running the client sends another request. I want to locate the first request and send it a stop signal.
Background:
I have a web service that requires 2-4 seconds to process. The servlet is hosted in a Tomcat container and is using OSGi to access the main processor in another plugin.
The requests come from another web site that allows users to make 10 or so requests at a time. While the user is waiting they may make another page change that will start another 10 web requests. I need a way to locate the previous requests. Then I'll find a way to send a stop signal to the long running process which will allow the original HttpRequest to finish with some suitable error code.
Perhaps another way to look at this problem is to say: if a client makes a series of requests that overlap then we only want to service the last request and cancel the previous requests as soon as possible.
I don't think HttpSession gives you what you are looking for, but I would recommend making some kind of object that your requests can periodically check to see if they are the "newest" request. If they are no longer the newest request then they can stop themselves and return immediately.
You can keep the previous request job task in the session. And on next parallel request, you can get the earlier request job and take the action you want.