有几百用户等待而阻塞的系统毛病出在哪?

chinahorse2003 2002-07-22 05:54:12

asp做的系统，开始每秒能写几条记录，用户多或时间长后几秒才能写一个，慢死了！
服务器配置：IBM PC 服务器 P4 1.7*2 2G内存
数据库系统MS SQL SERVER 2000
数据库几万条记录 (很少)
从机理角度考虑是什么原因呢?

出问题时服务器的内存或CPU利用率不高哇.

...全文

68 4 打赏收藏举报

写回复

4 条回复

切换为时间正序

请发表友善的回复…

发表回复

chinahorse2003 2002-07-22

打赏
举报

回复

少量用户情况下没有任何问题,

怎么模拟达到大量用户的情况呢?

epowerlab 2002-07-22

打赏
举报

回复

你可先自己用测试程序来试一下

如果没问题的话，应该是你程序的问题，拔除法找问题

chinahorse2003 2002-07-22

打赏
举报

回复

但也不至于支持不了几百用户吧?

君子藏器 2002-07-22

打赏
举报

回复

Asp解释性的语言本身效率就不高，用com组件可以提高速度。

在数据库并发访问中，锁等待是保证数据一致性的核心机制，但也是性能问题的常见诱因。SQL Server通过性能计数器Lock Waits/sec记录每秒的锁等待次数，它反映的是“频次”而非“时长”，仅凭数字高低无法判断系统是否真正受阻。理解其采集原理与正确解读方法，是DBA进行性能调优的基础。实际运维中，结合Lock Wait Time (ms)计算平均等待时长，再借助sys.dm_exec_requests等动态视图定位阻塞链，能高效找到问题源头。无论是高并发交易系统，还是日常任务引发的锁升级，掌握这套排查

同步、异步、阻塞与非阻塞是网络编程中最容易被混淆的基础概念，它们分别从调用方等待方式与线程状态两个不同维度刻画I/O行为。理解两者的排列组合，才能理清BIO、NIO、多路复用直至io_uring等模型的设计脉络。多路复用（如epoll）通过单线程监控海量连接，让有限线程支撑高并发；异步I/O则进一步将数据搬运交给内核。实际选型需根据连接数、I/O密集程度与团队技术栈权衡，避免盲目追求异步。只有看清同步阻塞、同步非阻塞、异步阻塞与异步非阻塞的本质，才能构建稳定高效的高并发网络服务。

网络应用的高并发性能，核心在于IO模型的选择。传统阻塞IO下，每个连接占用一个线程，线程上下文切换和内存消耗成为限制并发规模的主要瓶颈。作为解决C10K问题的关键技术，IO多路复用允许多个连接共用一个线程，即使使用select/poll这类全量扫描机制，也能显著减少线程数量。Linux下更高效的epoll则彻底改变事件通知方式，通过红黑树管理和就绪链表回调，将事件处理复杂度从O(n)降到O(1)。基于epoll构建的Reactor模型，配合事件循环和线程池，支撑了从Nginx到Netty等主流高性能框架。本

网络IO模型是理解高并发服务性能的关键起点。从阻塞IO到非阻塞IO，再到IO多路复用，epoll通过事件驱动机制让单线程同时管理海量连接，成为Nginx、Redis等组件的性能基石。Reactor模式进一步将连接监听与业务处理分离，Netty、Go协程等均在此基础上演化。理解这些原理，有助于在面对高并发场景时正确选型与调优，避免线程阻塞与资源浪费。全文从实战角度拆解五种IO模型及并发架构演进，并给出选型建议与踩坑经验，帮助开发者在真实项目中做出更合理的架构决策。

在高并发后端服务中，传统的阻塞式HTTP客户端往往因线程资源消耗过大而成为性能瓶颈。异步HTTP客户端通过事件驱动模型，将I/O等待从业务线程中剥离，让有限的线程资源支撑海量连接。Netty作为成熟的NIO框架，通过EventLoopGroup实现单线程串行化处理多个Channel，既避免了锁竞争又提升了吞吐。AsyncHttpClient正是基于Netty构建，由EventLoopGroup驱动请求发送、响应读取、连接复用与超时调度。理解这套底层机制，不仅能解释为何异步客户端能承载更高并发，也能帮助排查连

28,402

社区成员

356,940

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章