拜求方案:一个客户有300多个分布在全国各地的零售店,还要时时上传数据,如何做方案? ( 积分: 100 )

恩,是的,肯定的.

我测试了直接查询空表,也就是数据量最小的情况下,也就是压缩和不压缩没关系的情况下,我发现协议不同,区别还是挺大的,以前没研究过,呵呵,长见识了.

现在测试结果怎么样？

现在正跟 dbanywhere 开发组联系,计划用他们的最新版本的 dbanyhwere4.33-p2p的看看,这套组件的速度确实不错.

感谢各位的帮助,三拜.

祝贺你确定了自己的方案

觉得你现在的侧重点有偏离<br>第一重要的是中间层程序稳定性,你现在单机测试是不会发现什么问题,客户端一多你就知道问题了,速度是次要的,对你想要的方案,作为商业应用实时三层系统.要考虑容错性和负载均衡.<br>第二至于你担忧的网速问题,你可以考虑放到双线机房,在实际应用中,托管到电信机房,网通通过TCP协议访问,速度还是可以接受的.况且我认为你的数据量不会很大.传输的数据包要进行压缩,delphiDEMO中有例子.

我知道的,现在肯定要首先考虑远程效果测试的.<br><br>1:并发测试<br>2:稳定性测试<br>这才是最重要的,不能够只看速度.<br>我现在还在测试&nbsp;asta,remobject,dbanywhere这几个进行对比,<br>下一步的测试就是针对并发和稳定性,我计划找50台机器做些比较频繁的操作(比如循环),然后测试测试效果.<br>不怕不识货,就怕货比货,哈哈.

另外,客户不希望将服务器放到人家的机房,是自己装的光纤.这个是没办法改了.<br>这个实际的用户会在300左右,主要是零售,数据量到不是很大,我想的是只要能够速度快,达到我们要求的并发,比较稳定就可以了.我还要继续测试一段时间,一旦选定了一个,把软件做出来了,一上线不行那才叫郁闷呢,损失就大了,一定要进行压力测试,稳定性测试等,争取做好.

这么热闹来签个名!&nbsp;不知道现在还有人使用COM+&nbsp;做分布式开发没有啊!&nbsp;COM+&nbsp;能顶住同时在线200&nbsp;个客户端不?

用http连接，速度慢点，但是可同时在线的人可以增加很多&nbsp;<br>实际的用户会在300左右.<br>关键是要看同时在线的用户数，<br><br>我的想法，<br>稳定第一,速度第二。

http&nbsp;连接的也测试过了,及时响应速度太差了.

就从通讯协议来讲，在可靠传输协议中，TCP/IP是最快的，因为其它协议都在它之上，需要在它之上附带其它协议信息，TCP与UDP，谁快倒是不清楚，但UDP是不可靠传输协议，从稳定性讲，就不如TCP了，它是否会因为不可靠而给应用程序带来数据失真不得而之。<br>从asta,remobject,dbanywhere三个方案中，前两个都有公司做了测试而且有大量用户在使用，使用它们你还是可以放心的，第三者我就不清楚了。我以前的软件公司也对Remobject&nbsp;SDK作过压力测试，在30X24小时的测试通过后，采用了Remobject&nbsp;SDK作公司的软件平台中间件。

to&nbsp;:danng<br>给我也发个Demo怎样<br>先谢谢了<br>kevin.ko.cn@163.com

这两天我还看了一下协议方面的,在Tcp/ip协议族里面包含UDP和TCP,UDP是数据报协议,TCP是数据流协议,UDP和TCP都是建立在IP层的传输之上的.TCP协议本身已经已经做了完整的算法,对于丢包重发,发包顺序,拥塞控制等都做了处理,属于和式上升,积式下降.&nbsp;而UDP没有做任何的处理,直接发包,对于丢包等是不做任何处理的.就从用的简单性上来说,TCP是最简单的,因为协议本身已经做了处理.所以UDP的可靠传输就显的复杂多了(我没写过,不知道有多复杂).但我看到网上有很多关于UDP使用的描述,如果可靠传输写好了,效率确实非常的高,而且资源占用也是非常小.<br>&nbsp;&nbsp;&nbsp;&nbsp;作为使用者来说,我考虑的是稳定,并发,速度是几个关键的,具体底层是怎么写的,我是不怎么关心的,只要满足我的需求就可以了,哈哈.<br>&nbsp;&nbsp;&nbsp;&nbsp;在同网的测试中(我和几个同事都用adsl连接用adsl做的服务器),asta,remobject,dbanywhere反映都还是不错的,速度都可以接受.但asta,remobject在异网的测试确实是不太满意,卡的厉害,还时不时的出现网络中断现象.dbanywhere反映就好多了,没出现一次网络中断,反映速度还是很不错.<br>&nbsp;&nbsp;&nbsp;当然,速度不是最关键的,稳定第一,我正循环查询海量数据,不让程序停,'蹂躏'服务器端,哈哈,看看哪个顶的住.<br>&nbsp;&nbsp;&nbsp;说实话,dbanywhere是国内做的,我也关注了一段时间了,这次测试用的他们的最新版本,看看最后测试如何吧,首先支持一下国产(担心总是有的),哈哈.<br>&nbsp;&nbsp;&nbsp;从使用简单程度上来说,我到是比较看好dbanywhere,使用和他们说的ado,bde差不多,这个也是差不多,看看就明白了.<br>&nbsp;&nbsp;&nbsp;我先继续测试,最后由老板来定,源代码一定需要的,支持一下正版,反正也不是我花钱买.<br>&nbsp;&nbsp;&nbsp;感谢各位的帮助,我会继续把测试结果告诉大家,给大家一个参考.<br><br>最后,&nbsp;to&nbsp;danng:<br>我测试你的demo的时候,在测试环境中,多次出现:<br>&nbsp;&nbsp;执行错误:可能是由于网络已经断开.<br>&nbsp;&nbsp;connect&nbsp;reset&nbsp;by&nbsp;peer.<br>有时候出现:<br>&nbsp;&nbsp;执行错误:可能是由于网络已经断开.<br>&nbsp;&nbsp;详细信息:Invalid&nbsp;binary&nbsp;header....<br>&nbsp;&nbsp;后面是一堆看不懂的XML&nbsp;&nbsp;&lt;?xml....&gt;&nbsp;&nbsp;<br><br>&nbsp;&nbsp;查询的数据也很少,而且卡的厉害,放到同网的服务器上还是可以的,速度也还不错.<br>&nbsp;&nbsp;而且有个问题就是,后面的窗口总是不小心就跑到前面,好象是后面透过来的,很奇怪.

何必要建立连接直接查询呢？<br>给你个建议吧<br>在总部的服务器中建立FTP服务器，利用ｆｔｐ文件的方式传送变化的数据。<br>服务器定时生成特定格式的文件，客户端不断地扫描采集，然后处理到本地数据库中就可以了，主要处理变化的数据（即增量数据）。

呵呵,仔细看看我的要求,ftp的方式早落后多少年了.

看了楼主的需求，如果做成事到临头再去查价格，那么对响应速度自然要求很高（如果此<br>时断网，神仙也没招了）。如果可以将价格的查询和销售的上报做到一块，利用带时间戳<br>机制的价格表以及本地价格缓存，就能解决网络时滞可能造成的问题（除非您的服务端的报<br>价变化比股票还快，嘿嘿）。

呵呵,到不是这个意思,因为总部和分公司要时时远程查询销售情况,库存情况等,所以要求非常严格,客户也是这么要求,只要不断线,就要时时.这个也没办法.

就当我没有说吧，呵呵。<br>我这个是电信计费的解决方案。^_^