更新危急值系统的时候,有个科室的教授打电话过来,我刚抓起电话来,就感觉到了那粗重的呼吸与满肚子的怒气:“你们检验科在我们科室装的是个什么流氓软件,危急值确认不了,关还关不了,赶快来给我删了!”
这个软件流氓也没有360杀毒软件这么流氓吧。
矛盾总是相对立存在的,出了问题,怕是双方都有责任的。
一、旧系统面临的问题。
一开始这个危机报告系统是别人做的,老是有科室跑过来问,你们那个危急值报告系统,为什么确认了,它还是弹出来呢,严重影响我们的工作,我无奈,只得把服务端给关了,过30分钟后再打开,开发商来了三四次,竟是不知道原因在哪里!
他写的这个危急值系统,服务端用的是多线程的Sokcet写的,等于有200个连接就有200个线程,这么多的线程导致cpu和内存用量激增,更重要的是一旦到了190左右,客户端就莫名的掉线,就怎么都上不去了。
还有一个重要的原因,那就是缺乏处理措施,医生就还得拿个本子去记录危急值,没有完全电子化。
二、新系统要怎么做。
怎么做,当然是推到重来呗。详细见:
危急值报告系统是如何炼成的?
其它不再赘述,讲讲异步Sokcet遇到的问题:
在这之前,讲讲同步Sokcet的黏包问题:数据接收的时候,假设你的数据包一个是1024那么大,黏包就是你一次接收的数据可能会是2048、3076那么大,换言之,即便你发送是一个个包发的,接收都还是有可能黏包,那么这个时候你就必须把接收到的数据处理成分开成一个个1024的包了。
异步sokcet也会黏包么?不知道,没有遇到过,但是它会断包!
比如:
acceptSocket.BeginReceive(stateObject.ReceivedBuffer, stateObject.Read, StateObject.BUFFER_SIZE, 0, new AsyncCallback(Read_Callback), stateObject);
StateObject.BUFFER_SIZE的大小是1044,那么你以为收到的数据就是1044那么大的,即便是黏包,也是1044的整数了。
最后发现,不会黏包,但是会断包!,收到包的大小可能是628和416两个包!!!!
我花了一个上午的时间,才发现是这个原因,一开始还以为是解析数据出错。
那么,为了收到完整的数据,我们必须这么写回调函数:
int read = stateObject.WorkSocket.EndReceive(ar);
if (read > 0)
{
stateObject.Read += read;
if (stateObject.Read >= 1044)
{
stateObject.Read = 0;
DataPacket dp = SocketHelper.BytesToPacket(stateObject.ReceivedBuffer);
this.ReceivePacket(dp, stateObject);
}
终于不报错了!
使用异步Soket后系统性能大大增强,这个是对比:
程序线程:16:212。
占用内存:28M:56M。
CPU:0%:2%。
让我想到Node.js,非阻塞的异步编程,是未来的王道。
三、软件是如何流氓起来的。
护士:你们那个软件,没有声音提示,不在电脑面前就听不到。
我:那就加一个电脑主机蜂鸣器的报警!
护士:你们那个软件不弹出来!
我:有这回事!那我偷偷在后台加一个截屏。
一看傻眼了,哪里是不弹出来,弹出来后,她把它拉到左侧隐藏起来了,然后继续干她的活。
第一次改进:判断窗口在左侧隐藏,就挪到中间来!
她的对策:往左拉一下,靠!又弹回中间了,那就往下面拉!
第二次改进:判断窗口是否居中,居中就挪到中间来!
她的对策:往左,往右,往上,往下拉,靠!还是弹到中间来,流氓!
如无特别说明,本博客文章皆为原创。转载请说明,来自吵吵博客。
原文链接:http://chaochaoblog.com/archives/3309
吵吵微信朋友圈,请付款实名加入:
非常佩服!!检验人员能有这么强的编程能力!!
检验科能有你这种人才,是同科室人的莫大福气