解决方案 »

  1.   

    (1)提高解析程序本身的效能,对于现在的处理器(10GIPS性能级别),应该可以来得及处理10M数量级的数据(解析一个字节的数据使用1000条指令以下)
    (2)优化存储,包括异步读写、缓存、优化数据结构等等。工业实时数据库的设计是很高的知识产权。往往人家按照点数授权,1000点的报价都在几千美金以上,你应该和你的公司谈一个合理的价格,如果你就拿点工资就帮它搞定了,你亏大了。
      

  2.   

    不懂PLC DB块,不过5MB/s从数字上看并不大
      

  3.   

    并行编程,高效的socket框架,,这样 高并发的东西  大数据就不怕了.
      

  4.   


    5M的数据(Bety[])有优化解析方案?
      

  5.   

    不懂PLC DB块,所以不知道是个什么样的解析规则。
    就我接触过的协议数据解析一般都是O(n)的,如果有大量new操作应该使用对象池。
      

  6.   

    5M数据,而且每次读的间隔为1S左右。 关键是你能在1S把5M的数据转输完么?这才是问题 。现在的网络好像做不到
      

  7.   

    这个。。不知道能不能做到,大神 我想问问这5M的数据如何解析效率高些
    1.如果真的是每次都从PLC发5M数据过来,那建个发送缓冲区队列。 好比水库口出水量很大但河流(Socket发送的或接收的最大数)很小。那怎么办呢。
    那就在水库出口再建个蓄水区(这个可能有N大)把水库出来的水先放到这个蓄水区里,然后按量发河流。同样在接收流水的另一端,也要做这个蓄水区 然后再把蓄好的水进行业务处理当然你为了加快传输速度,那就把转输的数据进行压缩后,再发过去,然后对方接收到后,对数据进行解压。。不过这法子可能会在压缩上耗时间,所以你自己要视情况选择。。
      

  8.   

    如果楼主的数据是一次性发送的,1s能不能传输5M数据仅仅与硬件环境有关,现在最普通的网卡都是12.5MB/s的,与程序基本没有关系。
    楼主的CPU如果跟不上业务,就算把数据缓冲起来,内存数据只会越来越多,而且不实时,直到奔溃。除非楼主的服务器有大量的空闲期,能够在空闲期消耗掉这些数据。
    另外如果CPU资源本来就紧张,不应该启用压缩,压缩只会让CPU更紧张。
      

  9.   

    现在的服务器,标配8CPU,不可能不够用的,
    当然前提是多线程并发处理。
      

  10.   

    如果解析操作是CPU计算型的,并行度取决于CPU核心数。
    这种情况,不应该使用流水线,直接使用多线程一个线程处理一个数据就可以了。
    你可以看到每一个数据处理的起始时间与结束时间并不会因为流水线而变得更好,流水线仅仅是让程序更复杂了,而且增加了线程同步代价。流水线适应于IO与CPU交错的情况,比如楼主问题中的 网络与解析,这两个阶段就可以使用流水线技术。
      

  11.   

    这个。。不知道能不能做到,大神 我想问问这5M的数据如何解析效率高些
    1.如果真的是每次都从PLC发5M数据过来,那建个发送缓冲区队列。 好比水库口出水量很大但河流(Socket发送的或接收的最大数)很小。那怎么办呢。
    那就在水库出口再建个蓄水区(这个可能有N大)把水库出来的水先放到这个蓄水区里,然后按量发河流。同样在接收流水的另一端,也要做这个蓄水区 然后再把蓄好的水进行业务处理当然你为了加快传输速度,那就把转输的数据进行压缩后,再发过去,然后对方接收到后,对数据进行解压。。不过这法子可能会在压缩上耗时间,所以你自己要视情况选择。。压缩解压这中间消耗的时间可能无法接受,我想这种方法能够测试的。谢谢!
      

  12.   


    目前的环境好像是      一个PLC接很多生产线上的设备,然后PLC有生产线上的所有数据,而我们的系统连上PLC,读他的DB块,需要实时监控设备状态在加以控制。  现在卡在得到DB块数据之后的解析上。用多线程拆分数据,这样会提高速度?
      

  13.   

    如果解析数据是CPU计算型的(一般的解析都是),那么是否使用多线程拆分数据的关键在于你是否有空闲的CPU,一般来说你有几个核心就可以拆成几个线程处理(是并行处理,不是流水线)。