我遇到了类似的问题,但这是间歇性的。我有一个Oracle查询通常需要大约1秒才能运行,但有时在午餐时间使用.Net运行需要30秒。如果此时我在同一台机器上使用Oracle SQL Developer运行它仍需要1秒钟。
这个问题每天只持续约10分钟。我的同事也在同一时间得到同样的问题,同时也消失了。
所以它似乎可能是网络和.Net Oracle驱动程序的组合,但我不知道如何找到它。此外,其他SQL查询的执行速度也不慢,只有一个特定的查询只返回1200行。
编辑:我发现另一位同事在减速时通过网络进行大型文件复制。为了证明这一点,我让他再次这样做,同样的事情发生了 - 但是Oracle SQL Developer中的查询仍然很快。所以它是网络和.Net Oracle驱动程序的组合。我正在使用64位BTW。
“我可以将我的.net应用程序复制到oracle服务器并对其运行相同的性能测试,并在不到一秒的时间内完成。”
这是您的解决方案的根源。相同的app,测试中的受控元素,从一个位置移动到另一个位置,唯一变化的变量是网络。那么我们有两种可能性。可能性之一是网络本身就是问题,它太慢了。第二个是应用程序以及它与网络的接口方式与其性能相对立。
当然,服务器上的执行与VPN上的位置之间存在偏差。使用服务器上的导出功能(尽可能接近原始访问权限)应该允许您根据在VPN Connected主机上执行相同操作所需的时间长度的差异来测量网络差异组件。
但是,正如您所指出的,这不能解释诱惑时间差异。应用程序可能对WAN不友好。这通常意味着发送和接收信息需要太多的转弯,并且每个数据流中的信息量可能比需要的大得多。从批量导出到应用程序的底层握手机制可能完全不同。一个人可能一次请求100个记录,而另一个可能按顺序提取每个记录(注意你的速度差异为100:1)。对于单个记录拉动的数据库握手的持续应用可能会大大增加您的开销并导致吞吐量下降。
尝试增加获取大小 。越高,ODP.net为实际获取数据而必须进行的往返行程越少,网络上的性能就越好。 (请注意,如果启用了连接池,则AFAIK会自动完成。)
boomhauer:你到底了吗?我遇到了类似的问题。通过玩Fetchsizes,我确实得到了一点点提升。 在我的测试环境中,它比prod小一个数量级,我在ODP.net看到1.8秒,在System.Data.OracleClient看到0.2秒。 通过提升fetchsize可以获得的最佳效果是1.6秒。