关于音频直播服务器的并发数？

请问一下， V2EX 上有做音频直播服务器开发的童鞋吗？或者视频直播或 CDN 分发服务器的？

请教一下：你们的服务器用普通 PC 机子（比如：酷睿 i7 4 核 主频 2.0HZ ，操作系统 Linux 4.x ?），单进程能支持到多少的并发 socket ，机子配置如何？

我自己基于 RTMP 协议，用 objective-c 开发的单进程多线程模型的音频直播服务器，跑在酷睿 i7 4 核 主频 2.0HZ （机子 2012 年买的，可能已经不如现在的酷睿 i7 了， CPU 架构有所调整了），操作系统是 macOS 10.12 ，多路复用使用 poll （由于操作系统问题，没法使用更好的 epoll ），单进程能支持到 5k 个并发 socket ，这时 CPU 使用率已经快达到 70%（用户空间的 CPU 使用率接近 30%，系统空间的 CPU 使用率接近 40%），因为我只有一台机子，要同时跑服务器和客户端的测试程序，服务器支持 5k ，客户端也有 5k 的并发在跑，所以，如果机子只跑服务器程序的话，理想情况下可以达到 5k X 2 = 10k 的并发连接。。

服务器程序，我已经尽量做到 zero copy 了，减少了很多内存间复制，基本上只从 socket read 一次（数据从内核到用户空间），然后解析包头，包体等数据基本做到 zero copy 了，个人感觉没有优化空间了。。

服务器程序的 write socket ，使用 wrtitev 减少多次调用内核 write 函数（这样陷入内核软中断，进程上下文的切换会减少），感觉也没有优化空间了。。

因为是音频服务器，所以个人感觉使用 poll 和使用 epoll 的差别不大了，因为一个主播如果有 10k 的收听，基本一个音频包，就要转发 10k 次，这时， epoll 返回精确的 10k 可写事件和使用 poll ，然后遍历 10k 次没多大分别，但按理来说， epoll 肯定会优于 poll （如果是普通的即时文本通讯服务器的话，可能会有 2 倍的提升，但对于音频服务器的话，提升不大）。。

我开发的语言使用 objective-c ，函数的消息发送原理，内存的引用计数原理，感觉会带来一些额外过多的指令的执行，未如使用 c 开发的程序好。。

后期，可能使用 c ，和 c++各开发一次，跑在 Linux 上，使用 epoll ，看看并发数能突破什么界限。。

现在，感觉单机的并发数还是达到了我的理想，所以要开始写分布式了，进行服务器间的通讯。。