在产品设计过程中尽量只有请求服务器查询和变更数据才产生交互，降低 response 次数

从第二章考虑到 io 响应时间，响应时间会受到客户端等待时间，服务器返回时间和设备影响。

1. io response time

io 本身这里不介绍。
io 包含磁盘获取数据和操作系统和存储内部 io 等待时间。
io 性能监控在一些引擎里也是自带的，如果发现问题，需要网络层做优化处理。
Io 磁盘的缓存 cache 命中率是可以通过 free 查看的

2.Io 会存在哪些问题

在内网一些服务上跑生成大量数据的机器人，其他游戏的进程没有抛错，但你无法登陆。
Io 导致卡顿，游戏开发或者引擎自带工具来查看。
response time 时间 大于 xx 秒
动态加载过多和卸载资源，加大了 io 消耗，也会延长时间。
io 处理包较大，磁盘 io 缓存变低

网络层__declspec(dllexport)，初始化static BasicServer* GetBaseServer();当前连接数virtual int GetCurTcpHandle()=0; virtual int GetCurTcpIOPlus()=0;写回调

Iocp 于游戏方法之一

ASCENT_INLINE void SetCompletionPort(HANDLE cp) { m_completionPort = cp; }关联iocp端口，已完成的端口HANDLE m_completionPort;
//发起io计数同步
ASCENT_INLINE void IncSendLock() { InterlockedIncrement(&m_writeLock); }
ASCENT_INLINE void DecSendLock() { InterlockedDecrement(&m_writeLock); }

用异步 io 去处理，当没有发送成功则继续发送，但这里很容易会因为资源 network 和计算内容长度所影响，比如原来这个战斗文件 buffer 长度超出了，会降低 cahce 文件数量.

3. 优化方案

io 不需要用力优化，同时和武术一样，练硬功时会退步身法和软功一样。
限制一定时间内发包效率，最长用的办法。
当 io 出现大量阻塞时，可以检查线程数等待情况，所有线程数的返回时间，多线程处理是一定的方案，io 从连接和 io 实际操作是不够的，一定量的广播消息就堆包了。
根据业务来判断独立进程进行加载。

合并小包，减少请求数据次数，第一章讲到请求数<线程数问题，还要关注尺寸。
Unity 使用协程处理，cocos 也有对应等待方案
二次请求，可以做缓存区来减少响应时间

除了技术我们还有鼓励猫