Remoting使得访问数据库时间慢了6倍，大家说这正常吗？

Question

我们做的项目，原来是 IIS直接连接数据库  IIS <--> DB，
但是变态的客户非要说这样TMD不安全要我们在中间加一个Remoting服务器作为数据中转，于是变成了这样IIS <--> Remoting Server <--> DB ，这样倒是能运行，可是数据查询时间大大延长原来直接连接DB的时候搜索最极限数据需要20秒，可是加上Remoting Server后时间变成了2分钟。我是初学Remmoting，经验不是很丰富，大家说这种延迟正常吗？还是我需要改进我的Remoting程序？多谢

Answer 1

使用Remoting比直接访问慢这是肯定的，是不是正常，就要看他的速度是否还在可以接受的范围之内，从你给出的数据来看，2分钟显然是太慢了，你的设计可以改进，可能还要做大手术。在msdn看到一篇文章（不记得那一篇了）提到remoting+dataset是最慢的一种，如果你也是使用这种构架，那么建议你用实体类来代替DataSet。

Answer 2

如果我要返回大量数据的时候，不用DataSet，难道要生成无数个实体类返回？
有没有范例？

Answer 3

绝对不正常的,找找原因
还有就是,访问数据库采用remoting是非常不科学的方法,最好放弃!

Answer 4

up, thanks every one, any new Recommendations ？

Answer 5

Remoting 不能传输实体类,实体类不能够系列化

Answer 6

应该从 Remoting Server <--> DB 这段是走内网,内网应该不会明显的性能问题,可能是
Remoting Server中的内象没有释放,你看看Remoting的进程占用内存大小就知道了,由于Remoting Server的内存被占光,所以才慢, 需要定期调用GCC回收内存

Answer 7

感觉有点多余，如果黑客能入侵IIS那台服务器的话，在中间加多个Remoting Server又有多大意义呢？IIS <--> Remoting Server <--> DB这样一改肯定会慢不少的，不过相差6倍时间又确实有点夸张，单步跟踪一下你的代码吧，我觉得多数是代码本身有点问题^_^

Answer 8

IIS <--> Remoting Server <--> DB
这个用法很 wo cuo 谁想的是？序列化和反序列化的确很吃时间和内存，
不过慢 6 被有点离谱了，分段测试一下
Remoting Server <-- DB
IIS <-- Remoting Server分别消耗的时间
还有把你 IIS <-- Remoting Server 要传递的数据序列化到，文件看看 多大
如果大于 10M 就不要玩了，你就不能这么用了还有 Remoting 比 asp.net webServer 安全吗
那里来的理论啊，ms 都没说过的。Remoting 现在根本就不成熟，就是一个鸡肋安全不是靠语言，更不是靠编程方式的！

Answer 9

楼上所说极是。IIS <--> Remoting Server <--> DB
这个用法确实是很 wo cuo不是我不觉得Remoting是鸡肋。Remoting的安全确实是个大问题

Answer 10

你们客户真变态，有病……如果我要返回大量数据的时候，不用DataSet，难道要生成无数个实体类返回？
有没有范例？避免这样做，例如分页。