TongWeb中通道的线程任务队列大小（queueSize）和TCP等待队列大小（acceptCount）参数的含义和关系

优质文章学习记录

— 7 min read

TongWeb中通道maxQueueSize和acceptCount参数的含义和区别

在 TongWeb中，maxQueueSize 和 acceptCount 是两个与请求处理队列相关的核心参数，它们共同作用于并发请求的接收和处理流程，但所处的层面和作用机制有显著区别。理解两者的差异和协作关系，对优化 TongWeb 高并发性能至关重要。

  • 参数定义与作用

1. acceptCount（操作系统层面的连接队列）

  • 作用：控制操作系统内核维护的 TCP 连接队列（backlog 队列） 的最大长度。当 TongWeb 的工作线程全部忙碌时，新到来的 TCP 连接会先进入该队列等待，直到有线程空闲后再被处理。
  • 本质：这是操作系统层面的队列，用于暂存 “已建立但未被 TongWeb 应用层处理” 的 TCP 连接。
  • 默认值：TongWeb8企业版默认值为500；TongWeb7嵌入式版本默认值为100。
  • 队列满时的行为：若队列已满，新的 TCP 连接会被操作系统直接拒绝，客户端会收到 “Connection Refused” 错误（无法建立连接）。

2. maxQueueSize（TongWeb 应用层面的请求队列）

  • 作用：控制 TongWeb 应用内部维护的 请求处理队列 的最大长度。当所有工作线程（由 maxThreads 控制）都在处理请求时，已建立 TCP 连接的请求会进入该队列等待线程空闲。
  • 本质：这是 TongWeb 应用层的队列，用于暂存 “已建立连接但未被线程处理” 的 HTTP 请求。
  • 默认值：TongWeb8企业版默认值为100000；TongWeb7嵌入式版本默认值未知（无限制？）,且只能通过代码配置。
  • 队列满时的行为：若队列已满，TongWeb 会直接拒绝请求，并返回 HTTP 503 Service Unavailable 错误（连接已建立，但请求被拒绝处理）。
  • 工作流程与协作关系

当客户端向 TongWeb 发送请求时，流程如下：

  1. 建立 TCP 连接：客户端先与 TongWeb 服务器建立 TCP 连接，若此时 TongWeb 工作线程空闲，连接会直接被处理；
  2. 进入 acceptCount 队列：若工作线程全部忙碌，新的 TCP 连接会进入操作系统的 acceptCount 队列等待；
  3. 进入 maxQueueSize 队列：当工作线程从 acceptCount 队列中取出连接后，若线程仍忙碌，请求会被放入 TongWeb 应用层的 maxQueueSize 队列等待；
  4. 处理请求：工作线程空闲时，从 maxQueueSize 队列中取出请求并执行。

示意图：

客户端请求 → TCP 握手 → [acceptCount 队列（操作系统）] → [maxQueueSize 队列（TongWeb 应用）] → 工作线程处理

  • 核心区别

维度

acceptCount

maxQueueSize

作用层面

操作系统内核（TCP 连接层）

TongWeb 应用层（HTTP 请求处理层）

队列内容

暂存 “已建立但未被 TongWeb 处理” 的 TCP 连接

暂存 “已被 TongWeb 接收但未被线程处理” 的 HTTP 请求

满队列行为

拒绝 TCP 连接（返回 Connection Refused）

拒绝 HTTP 请求（返回 503 错误）

依赖条件

与操作系统内核参数（如 net.core.somaxconn）相关

仅依赖 TongWeb 应用配置，与操作系统无关

版本支持

所有 TongWeb 版本均支持配置

TongWeb7嵌入式版本只能通过代码配置

默认值

TongWeb8企业版本500、TongWeb7嵌入式版100

TongWeb8企业版100000；TongWeb7嵌入式版本未知（无限制？）

  • 配置建议
  1. 高并发场景：
    • 若客户端频繁出现 Connection Refused，说明 acceptCount 过小，需增大（如调整为 200-500）；
    • 若频繁出现 503 错误，说明 maxQueueSize 或工作线程（maxThreads）不足，需根据请求处理耗时调整队列长度或增加线程数。
  2. 参数配合：
    • 通常 maxQueueSize 应大于 acceptCount，避免应用层队列先满导致请求被拒绝；
  3. TongWeb8企业版本配置示例

在TongWeb8的通道配置中，有

<connector SSLDisableCompression="true" SSLDisableSessionTickets="false" SSLEnabled="false" SSLHonorCipherOrder="false" SSLVerifyClient="NONE" SSLVerifyDepth="10" URIEncoding="UTF-8" acceptCount="500" address="0.0.0.0" algorithm="SunX509" allowHostHeaderMismatch="false" allowMethods="GET,POST" asyncTimeout="30000" clientAuth="false" compressibleMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml" compression="off" compressionMinSize="2048" connectionLinger="-1" connectionTimeout="60000" connectionUploadTimeout="300000" defaultSSLHostConfigName="_default_" disableUploadTimeout="true" discardFacades="false" enableKAE="false" enableLookups="false" encodedSolidusHandling="reject" gmEnabled="false" http2Enabled="false" httpRedirect="true" ignoreHeader="false" keepAliveTimeout="60000" keystoreFile="conf/server.keystore" keystoreType="JKS" maxConnections="10000" maxCookieCount="200" maxExtensionSize="8192" maxHeaderCount="100" maxHttpHeaderSize="8192" maxKeepAliveRequests="1000" maxParameterCount="10000" maxPostSize="-1" maxSavePostSize="4096" maxSwallowSize="2097152" maxThreads="3" maxTrailerSize="8192" minSpareThreads="3" name="server" noCompressionStrongETag="true" parseBodyMethods="POST,PUT" pollerThreadCount="1" pollerThreadPriority="5" port="8088" portOffset="0" processorCache="1000" protocol="com.tongweb.coyote.http11.Http11NioProtocol" proxyPort="1" queueSize="100000" redirectPort="443" relaxedPathChars="&quot;&lt;&gt;[\]^`{|}" relaxedQueryChars="&quot;&lt;&gt;[\]^`{|}" scheme="http" secure="false" selectorTimeout="1000" sendfileSize="48" serverRemoveAppProvidedValues="false" sessionCacheSize="-1" sessionTimeout="86400" skipCharsValidate="false" sniParseLimit="65536" systemManaged="true" tcpNoDelay="true" threadKeepAliveTime="60" threadPriority="5" throwOnFailure="false" trustMaxCertLength="10" truststoreAlgorithm="PKIX" truststoreType="JKS" useBodyEncodingForURI="false" useIPVHosts="false" useKeepAliveResponseHeader="false" useNetworkMonitor="false" useSendfile="false" useServerCipherSuitesOrder="false" useVirtualThreads="false" xpoweredBy="false"/>

  1. TongWeb7企业版配置示例

在TongWeb7嵌入式版本中的配置

server.port=8089

#设置tongweb的最大工作线程数

server.tongweb.max-threads=3

#最小工作线程，连接池中应用保护的最小空余线路数

server.tongweb.min-spare-threads=1

#最大的线程等待队列数，当线程满后，线程的请求会进入次队列数，如果等待队列满了会拒绝请求

server.tongweb.max-queue-size=3

#最大连接数

server.tongweb.max-connections=3

#最大的连接等待队列大小，当连接数满后，连接会进入次等待队列，等待队列满后，连接会被拒绝

server.tongweb.accept-count=3

TongWeb7.0..e.7之前版本的max-queue-size不能直接配置，需要在代码中添加配置参数，如下：

@Configuration
public class TongWebConfig {

    @Value("${server.tongweb.max-queue-size:100}")
    private int maxQueueSize;

    @Bean
    public WebServerFactoryCustomizer<TongWebServletWebServerFactory> webServerFactoryCustomizer() {
        return factory -> factory.addConnectorCustomizers(
                (TongWebConnectorCustomizer) connector -> {
                    // 从配置文件读取 maxQueueSize 的值，默认为 100
                    //int maxQueueSize = 3; // 可以替换为从配置文件读取的值
                    connector.setAttribute("maxQueueSize", maxQueueSize);
                }
        );
    }
}

  1. 监控与调优：
    • 通过 JMX 监控队列长度（如 acceptCount 使用率、maxQueueSize 排队数），避免队列过长导致请求超时；
    • 结合请求处理时间调整：若请求处理快（如 100ms 内），队列可设小些；若处理慢（如 1s+），队列可适当增大。
  • 总结
  • acceptCount 是 “连接入口” 的第一道防线，控制操作系统能暂存的最大连接数；
  • maxQueueSize 是 “请求处理” 的第二道防线，控制 TongWeb 应用能暂存的最大请求数；
  • 两者需配合 maxThreads（工作线程数）共同优化，避免因队列过小导致请求被拒，或队列过大导致内存溢出（OOM）。

Read more

AI辅助编程的边界探索：当Copilot学会写测试

AI辅助编程的边界探索：当Copilot学会写测试

👋 大家好，欢迎来到我的技术博客！ 📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。 🎯 本文将围绕人工智能这个话题展开，希望能为你带来一些启发或实用的参考。 🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！ 文章目录 * AI辅助编程的边界探索：当Copilot学会写测试 🚀 * 1. 从“写代码”到“验代码”：AI的新战场 ⚔️ * 场景设定：一个简单的支付网关模拟器 💳 * 2. 初级实验：AI能写出“Happy Path”吗？ ✅ * 3. 进阶实验：Mocking 与 外部依赖 🎭 * 4. 陷阱与幻觉：AI写测试时犯的那些错 🤪 * 案例 A：永远不会错的测试 * 案例 B：永远跑不通的断言 * 案例 C：复杂集成测试的无力 * 5. 人机协作：重新定义测试工作流 🤝 * 实践技巧：如何高效地让AI写测试？
大模型本地部署神器：llama.cpp使用介绍

大模型本地部署神器：llama.cpp使用介绍

介绍llama.cpp 本节主要介绍什么是llama.cpp，以及llama.cpp、llama、ollama的区别。同时说明一下GGUF这种模型文件格式。 什么是llama.cpp llama.cpp是一个由Georgi Gerganov开发的高性能C++库，主要目标是在各种硬件上（本地和云端）以最少的设置和最先进的性能实现大型语言模型推理。 主要特点： * 纯C/C++实现，没有任何依赖 * 对Apple Silicon（如M1/M2/M3芯片）提供一流支持 - 通过ARM NEON、Accelerate和Metal框架优化 * 支持x86架构的AVX、AVX2、AVX512和AMX指令集 * 支持1.5位、2位、3位、4位、5位、6位和8位整数量化，实现更快的推理和更低的内存使用 * 为NVIDIA GPU提供自定义CUDA内核（通过HIP支持AMD GPU，通过MUSA支持摩尔线程MTT GPU）
2026年AI编程工具推荐：从Copilot到Trae，开发者该如何选型？

2026年AI编程工具推荐：从Copilot到Trae，开发者该如何选型？

面对琳琅满目的AI编程工具，字节跳动的Trae正以其本土化优势和工程级代码生成能力，悄然改变着中国开发者的工作流。 “有没有一个能完美适应国内网络环境，理解中文开发需求的AI编程工具？” 当字节跳动推出Trae时，这个问题开始有了清晰答案。与需要科学上网的Cursor、订阅费用昂贵的GitHub Copilot不同，Trae作为原生AI IDE，深度结合了中国开发者的实际工作环境。 一个有趣的现象是，越来越多的中国开发者开始将Trae与VS Code的无缝迁移体验作为选择标准之一。这种“无感切换”正成为本土AI编程工具获取用户的关键策略。 01 核心选型维度 开发者选择AI编程工具时往往陷入功能对比的细节中，而忽略了更本质的匹配度问题。真正影响工作效率的，不是工具宣传的“强大功能”，而是工具与开发者身份、工作场景的契合程度。 对于中国开发者而言，选型维度需要特别增加本土化适配这一项。网络稳定性、中文语境理解、本地支付便利性以及是否符合国内数据安全法规，这些在评估海外工具时常被忽略的因素，实际上决定了工具能否真正融入日常工作流。 不同规模的团队对AI编程工具的需求差异显著

llama.cpp 多环境部署指南：从CPU到CUDA/Metal的高效推理实践

1. 环境准备：从零开始的硬件与软件栈 如果你和我一样，对在本地运行大模型充满好奇，但又不想被复杂的框架和庞大的资源消耗吓退，那 llama.cpp 绝对是你该试试的第一个项目。简单来说，它是一个用 C/C++ 编写的轻量级推理引擎，能把 Hugging Face 上那些动辄几十GB的模型，“瘦身”成几GB的 GGUF 格式文件，然后在你的电脑上——无论是 Mac 的 Apple Silicon 芯片，还是 Windows/Linux 的 CPU 或 NVIDIA GPU——流畅地跑起来。我最初接触它，就是想在不升级显卡的老电脑上体验一下 7B 参数模型的对话能力，结果发现它不仅能在 CPU 上跑，还能充分利用 GPU 加速，效果远超预期。