Forum

Hello,

We have carefully inspected your RFID server (Tencent Cloud Seoul, 2 vCPU / 7.5 GB). The conclusion is that the server itself is perfectly healthy, and there are no traffic or bandwidth restrictions on the Zeabur side:

• CPU load is 0.18 (very idle)
• 5.3 GB of 7.5 GB memory is available
• The system and k3s components have been running normally for 16 days without any restarts
• Your MySQL, Redis, and two RFID service pods are all in a Running state, with no errors in the logs
• We have not set any bandwidth limits or rate limiting on the dedicated server—this machine receives the full bandwidth provided by Tencent Cloud for this instance specification

Therefore, the issue where 'creating more than 200 records causes a timeout' is almost certainly not caused by the server itself, but by the 'cross-border network latency and instability' between your client (Mainland China) and the machine in Korea:

• When you previously deployed on Tencent Cloud in Mainland China, both the client and server were within China, with round-trip latency of only a few milliseconds
• After switching to Korea, every request must travel through international routes out of China, and round-trip latency typically increases to 30–100 ms (with occasional packet loss or throttling, especially during peak hours)
• If your application performs multiple synchronous database round-trips for each RFID record, once the latency is amplified, it will trigger a client-side timeout upon reaching a certain threshold (the ~200 records you are seeing)

Switching to Singapore will likely not solve the problem—for a client in Mainland China, latency to Singapore is usually worse (not better) than to Korea. If your client is primarily in Mainland China, the recommended order of solutions is:

1. Redeploy to Zeabur's Mainland China nodes (Aliyun/Tencent CN)—lowest latency, but requires ICP filing for external domains
2. Hong Kong node—latency is second only to Mainland nodes, and it is not affected by the GFW
3. If you wish to remain in Korea, we recommend the following optimizations for your RFID application layer:

• Change bulk inserts to batch inserts (write multiple records at once instead of one request per record)
• Extend the client-side timeout settings
• Ensure the database connection uses connection pooling to reduce the connection establishment cost for each request

If you need assistance evaluating the Mainland China or Hong Kong node options, please reply and we will continue to assist you.

Hello, thank you for your detailed check and explanation. I would like to add a scenario we actually tested: In our previous tests, our client was in Taiwan while the server was deployed in mainland China. Therefore, it was actually a cross-border connection at that time, not entirely internal to mainland China. Thus, the current situation (Taiwan → South Korea) compared to the previous one (Taiwan → mainland China) are both cross-border connections, which seems slightly different from the premise you mentioned that "the previous one was an internal connection with lower latency."

Could you please help further confirm if the main differences might be due to the following points:

1. The actual network path quality difference (latency, packet loss, etc.) between Taiwan → mainland China and Taiwan → South Korea.
2. The impact caused by accumulated request latency in high-volume data write scenarios.
3. Whether the application layer is currently using individual requests (rather than batching), which makes it easy to trigger timeouts when latency is amplified.

If convenient, I would also like to ask for recommended testing methods that could help us further clarify whether the bottleneck is primarily from the network, timeout settings, or the application layer write strategy.

Additionally, please help evaluate the Hong Kong node option. Thank you.