Increasing <buffer_size> in AT+WSCFG

[jacek12345]

Is your feature request related to a problem?

I need sending more WS data in one iteration by AT+WSSEND

Describe the solution you'd like.

Can You double max. buffer size (8192 B to 16384 B) ?

Describe alternatives you've considered.

If not, i have to limit the amount of data sent, which will limit performance.

Additional context.

No response

[ustccw]

@jacek12345 May I ask how you determined that this buffer_size would affect performance?

Based on our previous testing experience, throughput performance is usually limited by the interface-layer configuration. In most cases, performance is constrained by UART throughput.

In addition, this buffer_size is the WebSocket send buffer size. The received data is immediately copied into the internal TCP send window. In theory, increasing this buffer size does not significantly improve throughput. Increasing the TCP send window size may be more effective instead.

[jacek12345]

@ustccw I haven't verified this, but I suspect so. If the main application has 16,384 bytes of data that we want to send to the server, sending it in a single WebSocket packet, which still needs to be acknowledged by the server, should be more efficient than splitting it into two packets, each acknowledged by the server.
Of course, I'm talking about throughput from main application point of view, not the ESP-AT firmware.
I think that Your schema could be completed like this, where R0/S0 is responsible for:
1.  Protocol overhead: Each packet requires a header, checksum, acknowledgment handling, etc. Two packets = double the overhead.
2. Transmission interruptions: Sending one large packet means continuous transmission and only one acknowledgment.
3.  Latency: Each acknowledgment introduces waiting time (latency). Two acknowledgments = twice the waiting time.

[ustccw]

@jacek12345 Thank you very much for your detailed explanation and for sharing your perspective.

1. I understand your point regarding the R0/S0 overhead, and I agree that, from the main application¡¯s throughput point of view, sending 16,384 bytes as a single WebSocket message can indeed be more efficient than splitting the data into multiple messages, as it reduces per-message protocol overhead and acknowledgment handling.

2. In practical implementations, the R0/S0 overhead is usually quite small compared to the overall transmission cost. During WebSocket transmission, the data path is effectively serial: UART data is first fully received and then forwarded to the protocol stack. In this case, the total transmission time can be approximated as:

UART transmission time + network transmission time (RTT) + minor overhead
(such as task switching, interrupts, and protocol processing)

If UART transmission and network transmission can be pipelined and executed in parallel, much of the RTT latency can be hidden, which may provide a greater throughput improvement than increasing the WebSocket message size alone. The choice therefore depends on which optimization better fits your application requirements.

3. From an implementation standpoint:

• I can increase the buffer size to 16 KB and contribute this change to the common repository.
• However, enabling parallel UART and network transmission requires more intrusive changes and is not suitable for inclusion in the generic solution. If this optimization is needed, I would be happy to provide guidance with customized library for your specific use case.

Please let me know your preference, and thank you again for the constructive discussion.

[jacek12345]

@ustccw Thank You for discussion and proposed solutions.
Please increase available buffer size to 16K if it is not problem for ESP-AT project. I think this is enough optimisation in my case.
It is also convenient in my case, due to double interface service (Ethernet / LTE) in main application, since LTE interface uses 16K buffer. Glad to know that there is even more optimisation ways that can be used in more critical usecases.

[ustccw]

@jacek12345 Thanks again for your feedback and discussion.

• We have updated the common ESP-AT repository, and the WebSocket buffer size is now configurable up to 16 KB, matching your request.
• We also exposed the following API for your convenience:
  extern esp_websocket_client_handle_t esp_at_get_ws_client_handle_by_link_id(int link_id);
• With this API, you can override the AT+WSSEND command to further speed up WebSocket data transmission. You can refer to the uploaded at_custom_cmd.c example for implementation details.

Please feel free to try it and let us know if everything works as expected or if you need anything else.

Best regards.

[jacek12345]

@ustccw Thank You for update. I tried with 16KB buffer and it works. Unfortunatelly there is issue on my server app side. Problem with performance with 16KB packets. I get the best results now with 4KB packets. Performance drops with smaller and larger packets. We need to optimise on the server side, and I'll return to working with a 16KB buffer and try with override AT+WSSEND for speed up more.

[ustccw]

Thanks for the update.
Glad to hear 16KB works on ESP-AT. The performance issue on the server side makes sense.
Looking forward to the results after server optimization and AT+WSSEND override testing.