Basic Concepts
Socket.IO
Socket.IO is a code tool library for the web-based instant messaging technology. It mainly establishes connections based on the WebSocket protocol, while also using HTTP long polling as a backup solution. It supports instant, bidirectional, event-based communication. Its main features are as follows:
High performance: In most cases, it uses the WebSocket protocol to establish connections between the client and server, providing a bidirectional and low-latency communication channel.
Reliability: When a WebSocket connection cannot be established (for example, the browser does not support the WebSocket protocol or the WebSocket connection is intercepted by a proxy or firewall), it will use HTTP long polling as a backup solution. Additionally, if the connection is lost, the client will automatically retry the connection.
Scalability: It supports deploying applications on multiple servers and sending events to all connected clients.
WebSocket
WebSocket is an application-layer communication protocol that provides full-duplex communication over a single TCP connection.
Unlike the HTTP protocol's question-and-answer mode where the client initiates a request and the server responds, once a WebSocket connection is established, data can be continuously and bidirectionally exchanged between the client and server until the connection is closed.
HTTP Long Polling
HTTP long polling is a web-based instant messaging technology based on the HTTP protocol. When the server receives a request from the client, it does not respond immediately but suspends the request first to check whether there is any data update on the server side:
If there is data update, the server returns the response normally.
If there is no data update, the server returns the response after the timeout interval set on the server side is reached.
After the client processes the response returned by the server, it will send the request again to re-establish the connection.
Compared with HTTP short polling, in the HTTP long polling mode, the client does not frequently send requests when there is no data update, reducing unnecessary requests and saving resources.
Introduction to Socket.IO-based Performance Testing
In PTS scenarios, scripts based on Socket.IO requests differ in structure and action mechanism from scripts based on HTTP requests:
Each VU that executes the HTTP script will continuously iterate the main function (export default function() { ... }) until the performance testing ends.
Each VU that executes the Socket.IO script does not continuously iterate the main function, because the main function is blocked by the io.connect method that establishes the connection, until the connection is closed. However, in the callback function (function (socket) {...}) after the connection is established, asynchronous events will be continuously listened on and processed until the performance testing ends.
Script Writing
The Socket.IO module of the PTS API provides APIs related to the Socket.IO protocol. For details, see pts/socketio. By using these APIs, you can establish Socket.IO connections and send/receive event messages.
Basic usage:
Use the connect method to establish a connection and define your business logic in its callback function:
The required parameters for this method include the URL of the service to be connected and the callback function to be executed upon successful connection.
The optional parameters for this method include configuration options:
protocol: protocol type, which supports polling (HTTP long polling) and websocket (WebSocket).
headers: request header parameters.
If the connection is successfully established, PTS will pass the created SocketIO object to the callback function. In the callback function, you can define your Socket.IO request logic and send/receive event messages.
After executing the callback function, the connect method will return a Response object with a return code of 200 indicating success.
Common methods of the SocketIO object:
emit: sends an event. Involved parameters include the event name, message data, and callback function.
event: custom event name.
msg: text message or binary data.
callback: (optional) callback function.
close: closes a connection.
on: listens on events and processes them with the callback function. PTS supports listening on the following events.
|
open | Establishes a connection. |
close | Closes a connection. |
error | Reports an error. |
message | Receives a text message. |
binaryMessage | Receives a binary message. |
setTimeout: executes the function after waiting for intervalMs milliseconds.
setInterval: periodically executes the function every intervalMs milliseconds.
setLoop: cyclically executes the function until the context ends or the connection is closed.
Below is an example code:
import socketio from 'pts/socketio';
import { check, sleep } from 'pts';
import util from 'pts/util';
export default function () {
const res = socketio.connect('http://localhost:8080', function (socket) {
socket.on('open', () => console.log('connected'));
socket.on('message', (data) => console.log('message received: ', data));
socket.on('binaryMessage', (data) => console.log('binaryMessage received: ', data));
socket.on('close', () => console.log('disconnected'));
socket.setTimeout(function () {
console.log('3 seconds passed, closing the socket');
socket.close();
}, 3000);
socket.setTimeout(function () {
socket.emit('message', 'hello');
socket.emit('binaryMessage', util.base64Decoding('aGVsbG8=', 'std', 'b'));
socket.emit('ackMessage', 'hello ack', function(msg) {
console.log('ack message received: ', msg)
})
}, 500);
socket.setInterval(function(){
socket.emit('message', 'interval message');
}, 500);
socket.setLoop(function () {
sleep(0.1);
socket.emit('message', 'loop message');
});
}, {
protocol:'websocket',
headers: {
token: 'xxx',
}
});
check('status is 200', () => res.status === 200);
}
Script Verification
To verify the script execution results, you can use the PTS debugging feature to quickly verify whether the results meet expectations before the formal performance testing. For more details, see Debug Scenario. File Dependency
In the performance testing scenario, you can upload the following types of files to provide status data during the execution of the performance testing task:
Parameter file: It dynamically provides test data in CSV format. That is, when the scenario is executed by each concurrent user (VU), each line of data will be obtained from the parameter file as the test data values for reference by variables in the script. For specific usage, see Using Parameter Files. Request file: It is required for constructing your request, for example, the file that needs to be uploaded. For specific usage, see Using Request Files. Protocol file: It is required for request serialization. For specific usage, see Using Protocol Files.