我认为可以先找瓶颈，因为每个人的环境是不一样的，所以优化的方案肯定也不一样。对于全行情录制的话基本上分为三个环节：

1. CTP服务器到脚本机
2. 脚本机到数据库
3. 数据库写盘

可以先隔离每一部分的代码来测试

1. 比方说只连CTP接口，但是不做数据库写入，然后在收到TickData的时候打印一下Tick的时间和本地时间，如果相差太多就说明CTP服务器到脚本机的网络不行，这时解决方案就是距离CTP服务器更近的地方部署服务器
2. 如果脚本机到数据库也走网络的话，需要考虑两方面的因素，延迟与吞吐量，延迟可以用ping的方式来探测，吞吐量可以直接查看网卡io的数据，看一下是否到达网卡上限，如果没到网卡上限但速度也不快的话也有可能是wifi导致的不稳定或者网线需要换成6类线或者更高规格
3. 如果是数据库机器硬盘io过高的话，那就有可能需要在第三个环节进行调优，软的方面把逐条插入改为批量插入，硬的方面可以选用高性能的ssd硬盘，关闭atime，做raid，取消实时备份等功能
4. 还有可能是数据库CPU过高，这也是需要改批量插入或者换更牛的CPU
5. 为了解决数据库性能瓶颈，可以考虑做分表分库，也就是说不同的合约考虑发到不同的数据库服务器上。或者做的更极端一些我们可以从最开始的脚本机就做拆分，比方说两台或更多台独立脚本机对应各自的数据库服务器，每组监听不同的合约

为了方便 vnstation 登陆，不然每次都要找手机登陆一下