Workerman最大连接数受限于应用配置和系统文件描述符，需同时设置Worker::$maxConnections和ulimit -n，否则连接数将受系统限制无法提升。
Workerman的最大连接数设置，核心在于两个层面：Workerman应用自身的配置，以及操作系统层面的限制。通常情况下，我们会通过修改Workerman脚本中的
Worker::$maxConnections
属性来指定一个上限，同时，PHP的
max_user_connections
（虽然Workerman通常不直接受此影响，但在某些特定PHP-FPM环境下可能需要考虑）以及更关键的操作系统文件描述符限制（
ulimit -n
）才是真正的瓶颈。如果这些系统级的限制不解除，Workerman内部设置得再高也无济于事。
解决方案
要设置Workerman的最大连接数，你需要关注以下几个关键点：
Workerman脚本内部配置
Worker::$maxConnections
：这是Workerman应用层面的直接限制。你可以在你的Workerman启动脚本中，在
Worker
实例创建之前，或者直接在
Worker
类中（如果它是全局配置），设置这个静态属性。
maxConnections = 50000; // 注意：这里是实例属性，而非静态属性，优先级更高$worker->onConnect = function($connection) { echo "New connectionn";};$worker->onMessage = function($connection, $data) { $connection->send('Hello ' . $data);};$worker->onClose = function($connection) { echo "Connection closedn";};// 运行所有Worker实例Worker::runAll();?>
这里需要注意的是，
Worker::$maxConnections
是全局性的，它限制的是所有
Worker
实例的总连接数。如果你有多个
Worker
实例（例如，一个HTTP Worker，一个WebSocket Worker），它们会共享这个上限。如果你想针对某个特定
Worker
实例进行限制，可以使用
$worker->maxConnections
（实例属性），它会覆盖全局设置。
操作系统文件描述符限制（
ulimit -n
）：这是最常见也最容易被忽视的瓶颈。在Linux系统中，每个网络连接（包括Workerman的每个客户端连接）都会占用一个文件描述符（file descriptor）。默认情况下，这个限制可能很低（比如1024），远不能满足高并发需求。
临时修改： 在启动Workerman服务前，在终端执行：
ulimit -n 100000
这只对当前会话有效。
永久修改： 编辑
/etc/security/limits.conf
文件，添加以下两行（如果你的用户是
www
，就替换）：
* soft nofile 100000* hard nofile 100000
或者针对特定用户：
your_user soft nofile 100000your_user hard nofile 100000
保存后，可能需要重新登录或重启系统才能生效。同时，有时还需要修改
/etc/sysctl.conf
，添加或修改：
fs.file-max = 200000
然后执行
sysctl -p
使之生效。
fs.file-max
是系统级别的最大文件描述符总数。
PHP配置
max_user_connections
(通常不直接相关，但值得一提)：这个配置主要是针对MySQL等数据库连接的，它限制了单个PHP进程可以建立的数据库连接数。对于Workerman这种长连接应用，它自己管理客户端连接，通常不会直接受
php.ini
中的
max_user_connections
影响。但如果你的Workerman应用内部会创建大量数据库连接，那么这个设置就需要关注了。不过，一般来说，Workerman的性能瓶颈更多在于文件描述符和自身的业务逻辑处理能力。
Workerman最大连接数与系统文件描述符限制的关系是什么？
这其实是个老生常谈的问题，但又不得不提。Workerman作为一款高性能的PHP异步事件驱动框架，它能够处理大量并发连接，其核心机制就是利用了操作系统的I/O多路复用（如epoll）。每一个客户端连接到Workerman服务器，操作系统都会为其分配一个文件描述符。你可以把文件描述符想象成一个句柄，操作系统通过它来识别和管理这个连接。
如果你的系统默认文件描述符限制（
ulimit -n
）是1024，那么即使你在Workerman代码里把
Worker::$maxConnections
设置成10万，Workerman也最多只能接受1024个连接。一旦达到这个上限，新的连接请求就会被拒绝，客户端会看到“Connection refused”或者连接超时。
所以，要真正发挥Workerman的高并发能力，提高系统文件描述符的限制是第一步，也是最重要的一步。我通常会建议，将
ulimit -n
设置为一个远大于你预期最大并发连接数的值，比如10万甚至更多，当然这也要根据服务器的实际硬件资源来定。设置过高而硬件跟不上，那也是徒劳。检查当前限制可以通过
ulimit -n
命令，而查看系统总的文件描述符使用情况可以用
lsof | wc -l
或者
cat /proc/sys/fs/file-nr
。
调整Workerman连接数时需要考虑哪些PHP配置和服务器资源？
调整Workerman的连接数，绝不仅仅是改一个数字那么简单。这牵扯到整个服务器的资源分配和PHP环境的健康状况。
首先是服务器硬件资源：
CPU： 更多的连接意味着更多的事件处理、数据收发和业务逻辑计算。如果你的业务逻辑复杂，每个连接都会消耗CPU。当连接数达到一定规模时，CPU很容易成为瓶颈。我一般会推荐使用多核CPU，并合理配置Workerman的进程数（
Worker::$count
），让Workerman的子进程能够充分利用多核优势。内存（RAM）： 每个连接都会占用一定的内存，用于存储连接状态、接收/发送缓冲区等。虽然Workerman本身对单个连接的内存占用很小，但当连接数达到几十万甚至上百万时，总内存消耗就会非常可观。此外，你的业务逻辑中如果缓存大量数据、处理大文件等，也会显著增加内存压力。PHP的
memory_limit
虽然对Workerman的长连接进程影响相对较小（因为Workerman通常是常驻内存的，不像PHP-FPM那样请求结束就释放），但如果你的
onMessage
回调里有内存泄漏或者处理大对象，仍然可能导致进程内存暴涨。网络带宽： 如果你的Workerman应用是用来传输大量数据（比如实时音视频、大文件上传下载），那么网络带宽是不可忽视的。连接数再高，带宽不足也无法支撑实际的数据吞吐量。
其次是PHP环境配置：
php.ini
中的
memory_limit
： 尽管Workerman进程是长驻的，但如果你的业务逻辑中处理的数据量大，或者存在内存泄漏，
memory_limit
仍然会限制单个Workerman进程的最大内存使用。一旦超出，进程就会被杀死。
php.ini
中的
max_execution_time
： 对于Workerman这种异步事件驱动模式，
max_execution_time
通常不会产生直接影响，因为Workerman不会阻塞在单个请求上。但如果你的
onMessage
回调中包含了同步的、耗时长的操作（例如，长时间的数据库查询、文件I/O，或者调用外部API），那么这些操作可能会阻塞当前进程，影响其他连接的处理。在这种情况下，你需要考虑将这些耗时操作异步化，或者将它们放到单独的进程/线程中处理。PHP版本和扩展： 使用较新的PHP版本（如PHP 8+）通常会带来性能提升。同时，确保Workerman所需的扩展（如
event
、
posix
、
pcntl
等）都已正确安装和启用，并且版本兼容。
说到底，这些配置的调整，最终目的还是为了让Workerman能够在有限的服务器资源下，尽可能稳定、高效地处理更多的并发连接。这是一个持续优化和权衡的过程。
如何监控Workerman的连接数和性能以进行优化？
仅仅配置好最大连接数是不够的，你还需要一套有效的监控机制来确保Workerman运行在最佳状态，并在出现问题时能够及时发现并解决。
Workerman内置状态命令：Workerman自带了一个非常实用的状态命令，可以让你实时查看当前连接数、内存使用、请求数等信息。
php your_worker_script.php status
如果是在守护进程模式下运行，可以加上
-d
参数。这个命令会输出每个Worker进程的详细状态，包括当前连接数、总连接数、总请求数等，这是我日常排查问题时最常用的工具。
系统级文件描述符监控：
查看当前文件描述符使用情况：
lsof -p | wc -l
(查看单个Workerman进程的文件描述符数量)
lsof | grep "TCP" | wc -l
(查看系统所有TCP连接的文件描述符数量)
cat /proc/sys/fs/file-nr
(查看系统当前已分配和最大文件描述符数量)监控
ulimit -n
是否生效： 确保Workerman进程是以你设置的高
ulimit
值启动的。
网络连接状态监控：
netstat -nat | grep ESTABLISHED | wc -l
这个命令可以查看当前服务器所有处于
ESTABLISHED
状态的TCP连接数，可以作为Workerman总连接数的一个侧面印证。如果你只关心Workerman监听的端口，可以加上端口过滤：
netstat -nat | grep :2346 | grep ESTABLISHED | wc -l
服务器资源监控：
CPU和内存： 使用
top
、
htop
、
free -h
等命令实时查看CPU利用率、内存使用情况。如果Workerman进程的CPU或内存占用异常高，可能是业务逻辑存在性能瓶颈或内存泄漏。网络I/O：
iftop
或
nload
可以帮助你监控服务器的网络带宽使用情况，判断是否存在网络瓶颈。磁盘I/O： 如果你的Workerman应用涉及到文件读写，
iotop
或
iostat
可以监控磁盘I/O，防止磁盘成为瓶颈。
日志系统和告警：配置好Workerman的错误日志和访问日志，并通过ELK Stack（Elasticsearch, Logstash, Kibana）或Prometheus + Grafana等工具进行集中收集、分析和可视化。设置关键指标（如连接数、错误率、响应时间）的告警阈值，当超出阈值时及时通知，这样才能做到防患于未然。
通过这些监控手段，你可以更全面地了解Workerman的运行状况，及时发现并解决潜在的性能问题，确保你的Workerman应用能够稳定、高效地服务大量用户。
以上就是Workerman怎么设置最大连接数？Workerman连接限制配置？的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/151069.html
微信扫一扫 
支付宝扫一扫 
