SQL Server - Management Studio - Client Statistics - Wait time on server replies vs Client processing time
SQL Server - Management Studio - Client Statistics - Wait time on server replies vs Client processing time
'Wait time on server replies' is the time between the last request packet left the client and the very first response packet returned from the server. 'Client processing time' is the time between first response packet and last response packet. Btw, I couldn't find the documentation to back these claims, but I'd say, based on my observations, that they are valid educated guess.
If you run a query with a large 'wait time on server replies' it means the server took long time to produce the very first row. This is usual on queries that have operators that need the entire sub-query to evaluate before they proceed (typical example is sort operators).
On the other hand a query with a very small 'wait time on server replies' means that the query was able to return the first row fast. However a long 'client processing time' does not necessarily implies the client spent a lot of time processing and the server was blocked waiting on the client. It can simply mean that the server continued to return rows from the result and this is how long it took until the very last row was returned.
What you see is the result of changes in the query plan that probably removed an operator that was blocking execution (most probably a sort) and the new plan uses a different strategy that produces the first result faster (probably uses an index that guarantees the requested order so no sort i needed), but overall last longer.
If you are worried about the client holding back the server (it can happen on large result sets) then you should investigate the wait_type
in sys.dm_exec_requests
(also info from sys.dm_os_tasks
and sys.dm_os_workers
is usefull) for the session executing the query under investigation. If I'm not mistaken the server waiting on client wait type is ASYNC_NETWORK_IO
. You can also check the aggregate sys.dm_os_wait_stats
, reset it using DBCC SQLPERF("sys.dm_os_wait_stats" , CLEAR)
then run the query, see how long the ASYNC_NETWORK_IO wait type adds up. Of course, make sure no other activity occurs on the server during the test.
作者:Chuck Lu GitHub |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
2020-06-20 哈佛大学公开课 幸福课 积极心理学
2019-06-20 Ajax
2019-06-20 jQuery FileUpload doesn't trigger 'done'
2019-06-20 Sending forms through JavaScript[form提交 form data]
2019-06-20 Sending form data
2019-06-20 Your first HTML form
2019-06-20 form submission