Backend Development 10 min read

Design, Implementation, and Testing of a WebSocket‑Based IM System

This article describes how Zhaozhuan replaced third‑party IM solutions with a custom WebSocket‑based instant‑messaging system, covering background, WebSocket fundamentals, implementation choices, detailed client code, multi‑stage testing (pre‑test, functional, online monitoring), automation with Puppeteer, performance testing using JMeter, and monitoring platform integration.

转转QA
转转QA
转转QA
Design, Implementation, and Testing of a WebSocket‑Based IM System

Background – Zhaozhuan’s rapidly growing business required a self‑built IM system to replace third‑party solutions that limited performance and efficiency.

WebSocket Overview – WebSocket provides full‑duplex communication over a single TCP connection, differing from HTTP and raw sockets. It eliminates the latency, authentication overhead, and traffic waste of short/long polling.

IM Implementation Options – The article compares short polling, long polling, and WebSocket long connections, concluding that WebSocket best satisfies real‑time and stability requirements.

Chosen Solution – A WebSocket‑based IM system was implemented using two client instances (UserWebSocketClient and KefuWebSocketClient) to simulate user and客服端, supporting text, emoji, image, product, order messages, session transfer, seat status, and queuing.

Client Code Example

public class UserLoginSendMsg {
    private static WebSocketClient chatclient = null;
    public static void testRun() throws Exception {
        chatclient = new WebSocketClient(new URI(URI), new Draft_17(), header, 500) {
            @Override
            public void onOpen(ServerHandshake handshakedata) {
                // establish handshake
                this.send("...");
                // heartbeat loop
                service.execute(() -> {
                    while (!this.getConnection().isClosed()) {
                        this.send("heartbeat");
                    }
                });
            }
            @Override
            public void onMessage(String message) {
                // business logic
            }
            @Override
            public void onClose(int code, String reason, boolean remote) {
                System.out.println("Connection closed");
            }
            @Override
            public void onError(Exception ex) {
                System.out.println(ex.getMessage());
            }
        };
        trustAllHosts(chatclient);
        if (chatclient != null) {
            chatclient.connectBlocking();
        }
    }
}

Testing Process – The overall testing is divided into three stages:

Pre‑test stage: develop and test WS client instances after requirement review.

Functional test stage: verify real‑time, reliability, reconnection, fault tolerance, security, and performance using timestamp measurements and massive message loops.

Online monitoring stage: use Puppeteer for UI automation, capture screenshots on failures, and push results to a monitoring platform.

Puppeteer Automation Example

async function mainProcess() {
    const browser = await puppeteer.launch({args:['--no-sandbox','--disable-setuid-sandbox']});
    const page = await browser.newPage();
    let cookies = await getData();
    await page.setCookie(cookies.cookie1);
    await page.setCookie(cookies.cookie2);
    try {
        await page.goto(url);
    } catch (e) {
        // capture screenshot on error
        const filename = Date.now() + '.png';
        await screenShot.screenshotMethod(page1, page2, filename);
        await browser.close();
    }
    await page.waitFor(2000);
}

Monitoring Platform – Failed cases generate screenshots and error logs, which are uploaded to a monitoring platform for review and further actions such as case management and manual triggering.

WebSocket Performance Testing – JMeter is used for load testing. Required JARs (websocket‑sampler, jetty‑http, jetty‑io, etc.) are placed in apache‑jmeter‑4.0\lib\ext . A Thread Group with a WebSocket Request‑Response Sampler is configured to simulate many concurrent connections and measure throughput, optionally adding HTTP Header Manager for authentication.

Conclusion – The custom WebSocket‑based IM system provides superior real‑time performance and stability, and the comprehensive testing framework (unit, functional, UI automation, and load testing) ensures reliability before production deployment.

PerformanceTestingbackend-developmentIM systemwebsocket
转转QA
Written by

转转QA

In the era of knowledge sharing, discover 转转QA from a new perspective.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.