TCP 客户端服务器:阻塞连接调用

发布于 2024-10-26 15:13:44 字数 547 浏览 3 评论 0原文

我正在构建一个需要 TCP 进行通信的分布式应用程序。最终的实验将涉及数千台服务器,与它们通信的客户端数量约为 10-100 倍。当前的设计是为每个事务建立连接、通信然后关闭连接。

  1. 由于我只做了一些带有几个客户端的简单多线程服务器,所以我选择阻塞套接字进行通信(它们听起来很简单)。我不确定这种方法是否会扩展得足够高。有人可以分享他们的经验吗?

  2. 目前,代码运行在一台机器(48 核/本地环回)上,具有三个服务器进程和一些客户端。客户端有一个紧密的 for 循环,它们在其中建立连接,与任何一台服务器通信,然后断开连接。这些初始测试要求客户端对 for 循环进行大约一百万次迭代。基本上,当我们扩大实验规模时,这是严格的测试。 随机地,一些客户端在尝试连接到服务器时被卡住。同时,该服务器可能与其他客户端通信良好。所有呼叫均被阻止。 有人可以建议发生了什么吗?服务器(多线程)的监听队列为 50 个,一个客户端每秒大约进行 1500 个连接。 (它是一个用于高端工作负载的分布式系统:)) 此客户端-服务器之间先前未中断的连接可能是一个原因吗?

任何经验分享都会有帮助...

I am building a distributed application that needs TCP for communication. The final experiments will involve thousands of servers with about 10-100 fold as many clients communicating with them. The current design is to make connection, communicate and then close the connection, for every transaction.

  1. Since I had only done some simple multi threaded servers with a few clients, I chose blocking sockets for the communication(they sounded easy). I am not sure if this approach will scale high enough. Can some one share their experience?

  2. Currently, the code is running on a single machine(48 cores/local loopback) with three servers processes and a few clients. Clients have a tight for loop where they make a connection, communicate with any one server and then break the connection. These initial tests require the clients to make somewhere like a million iterations of the for loop. Basically, it is rigorous testing as we scale the experiments up.
    Randomly, some of the clients get stuck while they try to connect to the server.At the sane time, this server may be communicating fine with other clients. All calls are blocking.
    Can some one suggest what's happening? The listen queue of the server(multi threaded) is 50 and one client does about 1500 connections a second. ( Its a distributed system for high end work loads :))
    Can a prior unbroken connection between this client-server be a reason?

Any sharing of experience would be helpful...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

不忘初心 2024-11-02 15:13:44

对于您提到的场景使用阻塞套接字可能不是一个好主意。首先,您应该使用非阻塞套接字。其次;如果您在 Microsoft Windows 上编写服务器,那么您可以考虑使用 I/O 完成端口来实现此目的,如果您的服务器在 Linux 上实现,那么使用“epoll”将具有良好的扩展性。

这里最大的问题是,从设计上看,您似乎在服务器上的每个线程管理一个套接字/连接。创建如此多的线程会耗尽系统资源,而且为每个连接创建线程的速度会更慢。

It might not be a good idea to use blocking sockets for the scenario that you mentioned. First things is that you should use non-blocking sockets. And secondly; If you are writing your server on Microsoft Windows then you can consider using I/O Completion Ports for the purpose and in case your sever is implemented on Linux then go for "epoll" will scale good.

The biggest issue here is that by design it seems like you are managing one socket/connection per thread on your server. And you will exhaust your system resources by creating so many threads and its slower to create thread for every connection.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文