在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
DataSetProviders的作用是把数据导出到外部世界,而ClientDataSets的功能是接收数据(并把请求和更新发送回DataSetProvider)。许多DataSnap客户端都可以连接到单个DataSnap服务器,向服务器请求数据,而服务器往往就是数据吞吐量瓶颈发生的地方。 让我们开始吧 让我们就从这个问题的解决开始,确认线路上发送数据的真实量是很有必要的。因此,我们不会去研究(请求和接收数据的)ClientDataSets,而是要研究一下DataSetProvider组件——它会回应数据请求从而发送数据。幸运的是,DataSetProvider组件有一些有用的虚拟方法,它们能够被用来强制替代(别的方法)以及包含我们的“追踪”代码,这样你就能够了解数据吞吐的真实情况。 一旦了解了情况,你就可以开始着手降低吞吐量了。当然,你不能因为能够优化就开始进行优化;总得有个原因。但是一旦有几百个客户端连接到你的DataSnap服务器,所有客户端都会请求成兆的数据,你就要因为这个原因而立即开始优化了。 DataSnap就是原来的MIDAS DataSnap技术是MIDAS的新名字,它在Delphi企业版里(或者C++Builder企业版里)被用来创建多层应用程序。当我谈到DataSnap的效率时,我主要关心的是数据吞吐量的瓶颈,包括限制从服务器层发送到客户层的数据量从而防止瓶颈的方法。在你能够限制吞吐量之前,你首先要测量它。 TB42DataSetProvider 在本文的后半部分里,我会假设你有一个DataSnap服务器和客户端可用。如果你需要的话,可以在Delphi6DemosMidasMstrDtl获得一个DataSnap主从复合结构(master-detail)的示例项目。为了测量数据量,你把TdataSetProvider组件用一个叫做TB42DataSetProvider的专用版本替换掉。新的组件有一个BytesTransferred属性,它会包含自从其被创建以来被传送的字节数量。 它会强制替代InternalGetRecords方法,以增加FbytesTransferred里的值,并报告所传送的字节数量,还会报告新的数据包已经被发送,包括记录的数目以及数据包的大小。这两个方法(见Listing A)会被ClientDataSet或者XMLBroker组件调用,用以响应DataSnap客户端的数据请求。 要注意,eBob42PRO单元里的代码会使用InternalGetRecords和CreateDataPacket方法里的简单writeln声明。这就意味着你必须把{$APPTYPE CONSOLE}这一行添加到你DataSnap服务器的主项目里,这样才能为调式的输出打开一个控制台窗口。如果你忘了做这个,那也不用担心DataSnap服务器会向你报I/O错误了,因为IsConsole的检查会确保writeln声明只在控制台应用程序里被确实地调用。 要使用这个组件很简单:把TB42DataSetProvider组件添加到组件调色盘里的一个Delphi工具包里,并使用TB42DataSetProvider替换掉你远程数据模块上的普通TdataSetProvider。 ClientDataSet的PacketRecords 使用ClientDataSet连接到DataSetProvider(它指向整个表格)的潜在危险之一是:当你打开ClientDataSet的时候,它会缺省地从DataSetProvider请求所有的数据。这就意味着(服务器端)表格的全部内容都要通过线路送到ClientDataSet。对于Delphi自己的示例数据库表格当然是没有问题的,举个例子的话,因为消费者和订单的表格所包含的记录会少于100条。但是,在现实生活中,公司的消费者会多于100个(而订单的数量会更多),获取所有客户(的信息)会花上一段时间,在你每次打开ClientDataSet的时候把表格的内容从DataSnap服务器发送到DataSnap客户端也要花上一段时间。 解决这个问题的一种方法是使用ClientDataSet组件的PacketRecords属性。这个属性会对数据的初始请求进行修改,让其包含被请求数据包的大小(以记录的形式)。所以如果有上千条记录存在的话,你只用取得文件X,而文件X是PacketRecords属性的值。在缺省条件下,这个属性被设置为-1,即“把所有的记录都给我”。 |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论