I'm trying to figure out how to do load testing on a long polling or web socket type of architecture.
I need to setup multiple clients which subscribe to channels on one side and wait for responses. The load testing should measure the time it took for messages from the publishing server to reach the clients.
Any ideas?
As said here,
SignalR uses a particular protocol to communicate so it's best that
you use our tool to generate load for testing your server(s).
So, SignalR comes with Crank. Crank can only connect to PersistentConnection based apps and not Hub based app.
This another answer could help you for Hub based app.
You can use crank, as referred above. One of the parameters is Transport, so you can specify only LongPolling:
crank.exe /Url:http://someUri /Transport:LongPolling
Use JMeter (https://jmeter.apache.org/) and flood with http connections with transport-type as header.
Related
We are trying to load test our login workflow, by simulating 50+ users logging into our front-end, via the API calls. As part of the login process, we make a websocket connection to a SignalR hub(Connect). We then send a call over the websocket connection to a custom endpoint in SignalR(Login), used to add some data to the Redis cache, then do some stuff which isn't important, then send a call to a different custom endpoint over the websocket connection(Logoff) and then Disconnect the websocket connection.
So my question is multi-part:
How do we create a websocket connection from within JMeter?
How do we make a call to a custom endpoint over the websocket connection in JMeter
How do we do this for multi users simulated to be running in parallel, so we can test the load? In other words, we need multiple websocket connections open / alive from JMeter so we can test the load.
Note: Please be aware, I'm asking this on behalf of the load tester/JMeter developer, but because they are new to Stack Overflow, and I understand the SignalR side, I've been asked to log it. I know zip about JMeter, so please handle me like a noob trying to help someone solve a frustrating but important problem.
JMeter per se doesn't support WebSockets, you will need a special plugin if you want to enable this functionality.
The most advanced, comprehensive and supported as of now is JMeter WebSocket Samplers by Peter Doornbosch, it can be installed using JMeter Plugins Manager
Once you install the plugin and restart JMeter you will see several new samplers which will allow to open connection, send request, read response, and close connection.
Unfortunately I cannot guide you further because I don't know the specifics of your application, just look into your browser developer tools or other sniffer tool and configure JMeter to send the same requests as your browser (or other application) does.
More information:
Test SignalR Performance with JMeter
JMeter WebSocket Samplers - A Practical Guide
samples directory contains several example test plans covering different scenarios
I am working on a project which is basically a Customer Feedback Analysis Dashboard. There are few graphs on the dashboard and data for each graph is fetched from the server through API requests.
Right now the dashboard is updated every time the page is refreshed. I want it to be updated immediately when there is a new feedback in the system. I am confused, whether I use websockets to send data for each graph or just a flag and use that flag to fetch data through API requests.
Like, facebook/twitter does. They tell you about new posts/tweets and when you click that button your feed/wall gets updated.
If you want to "push" data from server to client and you want that data to show up in a timely fashion (e.g. within 10-20 seconds of when it was available on the server), then you will want to implement some sort of "push" solution where the server can efficiently push data to the client whenever there is new data to send.
There are several possible approaches:
webSockets
socket.io
Server-sent events
Mobile platform-specific push (Android and iOS)
For a general purpose solution that works within a browser, you will want to use one of the first three. socket.io is built on top of webSockets (it just adds more features) so architecturally, they are similar.
Server-sent events are fairly new (modern browsers only) and are only for one way communication (from server to client). webSockets can be used for communication either way.
I'd personally recommend socket.io because of the features it offers (such as automatic client reconnection) and a simplified messaging layer. You can see the feature difference between socket.io and webSockets here. With socket.io, the client makes a connection to the server when the web page is loaded and that connection is persistent. After the connection is established, then either client or server can send messages to the other at any time in a very efficient manner.
Other useful references:
Push notification | is websocket mandatory?
websocket vs rest API for real time data?
Why to use websocket and what is the advantage of using it?
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
I have a concox GT06 device from which I want to send tracking data to my AWS Server.
The coding protocol manual that comes with it only explains the data structure and protocol.
How does my server receive the GPS data collected by my tracker?
Verify if your server allows you to open sockets, which most low cost solutions do NOT allow for security reasons (i recommend using an Amazon EC2 virtual machine as your platform).
Choose a port on which your application will listen to incoming data, verify if it is open (if not open it) and code your application (i use C++) to listen to that port.
Compile and run your application on the server (and make sure that it stays alive).
Configure your tracker (usually by sending an sms to it) to send data to your server's IP and to the port which your application is listening to.
If you are, as i suspect you are, just beginning, consider that you will invest 2 to 3 weeks to develop this solution from scratch. You might also consider looking for a predeveloped tracking platform, which may or may not be acceptable in terms of data security.
You can find examples and tutorials online. I am usually very open with my coding and would gladly send a copy of the socket server, but, in this case, for security reasons, i cannot do so.
Instead of direct parsing of TCP or UDP packets you may use simplified solution putting in-between middleware backends specialized in data parsing e.g. flespi.
In such approach you may use HTTP REST API to fetch each new portion of data from trackers sent to you dedicated IP:port (called channel) or even send standardized commands with HTTP REST to connected devices.
At the same time it is possible to open MQTT connection using standard libraries and receive converted into JSON messages from devices as MQTT in real time, which is even better then REST due to almost zero latency.
If you are using python you may take a look at open-source flespi_receiver library. In this approach with 10 lines of code you may have on your EC2 whole parsed into JSON messages from Concox GT06.
I would like to see if someone can clarify me some concepts I still don´t get about integration of web applications. Up until now, I´ve been working with CometD and Activemq in a project that´s been there for several years but, for what I´ve seen, there are other options out there much more simpler and supported by the community but I still don´t get the whole picture of options available.
So, for what I understand, at the moment, the most common way of getting server pushed events to a client is using websockets. The implementation is server specific and the most used one seems to be the Jetty one. But, because it requires a websocket compatible browser, there are some frameworks that are able to provide websockets and fall to reverse ajax techniques in case this is not an option, like SockJS, that has an implementation for client and for server side. Based on this, as of spring 4 there are templates that allow you to use SockJS behind the scenes and just provide the client implementation of the code using SockJS and letting the programmer to handle the server side in a more easy way.
Apart from this, brokers can understand the websocket protocol so a broker can receive a message from a web browser and then send a message back directly. There is also the STOMP protocol that brokers also implement that allows the system to send/receive messages through websocket to/from the web browser.
One question I have about this is, is STOMP the protocol always used by the broker to send or receive a message to or from a web browser? Or is just one alternative? What is the difference if it´s the later?
Yet another option I´ve seen is using a framework like camel. In this case, the web browser would talk to the websocket component of camel and from there it could be routed directly to the broker using jms. The benefit I see on this is the possibility of introducing processors as part of the route from the browser to the broker, allowing further security processing and reducing the traffic the broker would have to handle in case of not valid/unauthorized messages. Camel would even be able to listen to messages using the STOMP component what would be yet another routing option.
So, to this point, I don´t know if my understanding is correct or if I miss or misunderstand something. If everything is right, it seems that using a framework like SockJS is the best option available at the moment. The use of Spring 4 to simplify things is an option but not really necessary. If the project requires the integration of different systems using a jms broker, the implementation then falls to use SockJS to send messages to the server side and then just route the messages to the correct system. But at this point, there are the options mentioned before like using camel to route the messages or directly send messages to the broker. What would be the best option, or what would be the differences? If I add STOMP to the problem, what does this protocol give me that I can´t handle just with websockets or camel?
I hope I made myself clear. I think this topic includes several technologies and frameworks and it´s quite difficult to express all my concerns without extending the post to much.
Thanks in advance.
In a nutshell, if you want messaging semantics, you should use a messaging protocol such as STOMP. WebSockets sure can handle communication to browsers just fine, but that's just "any custom communication".
The system design may be cleaner if you design around the convention of topics and messaging. The server backend processes can easily push data to a topic that is propagated to all clients, ideally with no further customization.
Aside from STOMP, there is a similar protocol, MQTT which also can run over websockets. A chat demo is provided by ActiveMQ distribution. MQTT is very hot in the Machine2Machine world "internet of things", but I have used it with success in web-deployments too. MQTT should, at least in theory, run pretty good, with low overhead in phone apps, should you ever consider writing one side by side with your website. Then it can be good to use a single setup to communicate "push" data with your clients. Otherwise, your app may have used MQTT, your browser app would have used plain websocket, your backend would have needed another way to pass async events to clients (via some Camel router or similar) and so forth.
I've implemented a web chat system using Jabber, with the Tigase server and an Ajax-based client communicating over BOSH using JsJac, with Apache mod_proxy forwarding the HTTP traffic to Tigase. This works reasonably well, but I've noticed one major gap in performance versus a desktop Jabber client (like Exodus), particularly when joining a multi-user chat with a long history of messages.
Specifically, from monitoring HTTP traffic, it appears that the server can only send one XMPP message per HTTP request-response cycle. For normal usage this is fine (we're getting roughly 80-100msec round-trip times, which isn't too bad), but when loading MUC history it can be a real drag.
So my question is: does Jabber or BOSH provide any mechanism for bundling or streaming messages that might apply to this use case? Are any clients and servers out there implementing something like this already? Or would I have to modify Tigase and JsJac myself (which is certainly possible, but not ideal)?
Actually, the BOSH server can collect as many responses from the Jabber server and send them as one single response to the client. I am the author of one such BOSH library: http://code.google.com/p/node-xmpp-bosh/.
The response body has nothing to do with the request body in case of BOSH. I mean that the response could and mostly will be a response to an unrelated request (mostly a later request).
I have implemented a BOSH communications solution with Java on the server and GWT on the client (a browser). A C client implementation has also been made. Presently, I am in the process of making the solution available online for tests. Please take a look at the following Google presentation to see if my solution is relevant for your business:
https://docs.google.com/present/edit?id=0AUPL-u98h45WZGQzNWNjOGhfMGd6bWI1NmNk&hl=en&authkey=CPTzrWc
To see the speaker notes, make sure you hit the "View Speaker Notes" button in the bottom-right corner of the page.