RO, Remobjects读取数据速度的研究，希望一下
RO, Remobjects读取数据速度的研究，希望高手指点一下。
最近项目中采用RO、Remobjects技术，发现在数据传输上存在如下差异：
测试环境：
1 服务端（中间层）与客户端同一台机器
2 局域网内A电脑客户端，B电脑装中间件（服务端）
结果 第一种情况比第二种情况快10倍，第二种环境太慢，严重影响客户端程序运行速度。
3 取数据的方法是这样的，服务端有一函数将数据集data值转换成string(variantarraytostring( clientdataset.data) ) , 然后以返回值的形式返回给客户端。
请高手帮忙分析一下，怎么改进？
------解决方案--------------------
局域网速度是很快的，不至于这么低。
------解决方案--------------------
在同一情况下，本机的数据传输速度当然比局域网的数据传输速度快啦
------解决方案--------------------
差10倍？
如果0.01s和0.1s的差别，也是正常的
就是1s和10s的差别
我使用ini@https，局域网、adsl都感觉可以接受的
------解决方案--------------------
有没有看一下，局域网内是不是传输占了很长时间？
------解决方案--------------------
确是这样 ClientDataSet 数据量 超过2万条 就非常慢 好像猫似 无办法解决
我是 通过 ADOQuery.Recordset 将此转成 IDisptach 传出数据到客户端
就是 记录量 10万条 也是可以很快显示出来
------解决方案--------------------
多层的程序开发讲究的是多次少取，如果因为一次取出的记录数太多，需要在设计一下。如果记录数不多而出现等待时间过长的问题，就很不正常了。在实际应用中还没遇到这种问题。传输的时候先压缩一下吧，节省网络流量。
------解决方案--------------------
有一个小问题是,你没必要把clientdataset.data先转成字符串类型再传,这样估计也会花点时间.你直接传variant类型就行了,这样应该更快一点
------解决方案--------------------
局域网的速度应该能接近本机吧，网络环境很差？
------解决方案--------------------
一次取太少，但是每次的包头开销是固定的，所以肯定不如每次取中等大小的，太大，会出现一次长等待的体验
我说的0.01S和0.1S，是最终的体验
最初如果是这样的差距，慢的很可能定会在某个中间环节导致不可用（比如数据库并发连接数太多，因为每个连接的处理时间都长了10倍）
最近有一个关于C#慢的讨论，我的感觉也就是：快，是指不能慢到影响效果的程度
最终是人的等待能接受，中间是各个环节不会互相卡死（比如数据库连接全部占满了），最初的始作俑者，就是代码的执行效率
能满足最终结果的 代码的执行效率 ，就是够快了，再快，则意义也不大了
但是，不能满足最终结果的代价的执行效率，就是慢了，必须得加快
------解决方案--------------------
说明ado 取10万条 从一台机器到另一台机器很慢
最近项目中采用RO、Remobjects技术，发现在数据传输上存在如下差异：
测试环境：
1 服务端（中间层）与客户端同一台机器
2 局域网内A电脑客户端，B电脑装中间件（服务端）
结果 第一种情况比第二种情况快10倍，第二种环境太慢，严重影响客户端程序运行速度。
3 取数据的方法是这样的，服务端有一函数将数据集data值转换成string(variantarraytostring( clientdataset.data) ) , 然后以返回值的形式返回给客户端。
请高手帮忙分析一下，怎么改进？
------解决方案--------------------
局域网速度是很快的，不至于这么低。
------解决方案--------------------
在同一情况下，本机的数据传输速度当然比局域网的数据传输速度快啦
------解决方案--------------------
差10倍？
如果0.01s和0.1s的差别，也是正常的
就是1s和10s的差别
我使用ini@https，局域网、adsl都感觉可以接受的
------解决方案--------------------
有没有看一下，局域网内是不是传输占了很长时间？
------解决方案--------------------
确是这样 ClientDataSet 数据量 超过2万条 就非常慢 好像猫似 无办法解决
我是 通过 ADOQuery.Recordset 将此转成 IDisptach 传出数据到客户端
就是 记录量 10万条 也是可以很快显示出来
------解决方案--------------------
多层的程序开发讲究的是多次少取，如果因为一次取出的记录数太多，需要在设计一下。如果记录数不多而出现等待时间过长的问题，就很不正常了。在实际应用中还没遇到这种问题。传输的时候先压缩一下吧，节省网络流量。
------解决方案--------------------
有一个小问题是,你没必要把clientdataset.data先转成字符串类型再传,这样估计也会花点时间.你直接传variant类型就行了,这样应该更快一点
------解决方案--------------------
局域网的速度应该能接近本机吧，网络环境很差？
------解决方案--------------------
一次取太少，但是每次的包头开销是固定的，所以肯定不如每次取中等大小的，太大，会出现一次长等待的体验
我说的0.01S和0.1S，是最终的体验
最初如果是这样的差距，慢的很可能定会在某个中间环节导致不可用（比如数据库并发连接数太多，因为每个连接的处理时间都长了10倍）
最近有一个关于C#慢的讨论，我的感觉也就是：快，是指不能慢到影响效果的程度
最终是人的等待能接受，中间是各个环节不会互相卡死（比如数据库连接全部占满了），最初的始作俑者，就是代码的执行效率
能满足最终结果的 代码的执行效率 ，就是够快了，再快，则意义也不大了
但是，不能满足最终结果的代价的执行效率，就是慢了，必须得加快
------解决方案--------------------
说明ado 取10万条 从一台机器到另一台机器很慢