当网站远程访问本地时,MV.NET调用要慢得多

时间:2016-05-02 17:37:30

标签: asp.net iis pick multivalue-database

我有一个asp.net webforms页面,通过mv.net调用pick / d3。 我通过使用计时代码包围mv.net调用来记录服务器端性能,例如: logTimeElapsed() getDataFromPick() 'gets 5 rows of test data logTimeElapsed()

当我从托管iis服务器调用此页面时,我得到快速响应时间,例如: newAC elapsed: 2.9297 total: 2.9297 Dim Acct As mvAccount = New mvAccount("...") row 1 elapsed: 20.5078 total: 23.4375 Acct.FileOpen("...").ReadV(strID, 17) row 2 elapsed: 9.7657 total: 33.2032 same as above row 3 elapsed: 11.7187 total: 44.9219 same as above row 4 elapsed: 11.7188 total: 56.6407 same as above row 5 elapsed: 9.7656 total: 66.4063 same as above Logout elapsed: 1.9531 total: 68.3594 Acct.Logout()

但是,当我从网络上或网络上的其他位置调用同一页面时,我得到的响应时间大约是后者的7倍: new acct elapsed: 0 total: 0 Dim Acct As mvAccount = New mvAccount("...") row 1 elapsed: 156.25 total: 156.25 Acct.FileOpen("...").ReadV(strID, 17) row 2 elapsed: 78.125 total: 234.375 same as above row 3 elapsed: 78.125 total: 312.5 same as above row 4 elapsed: 78.125 total: 390.625 same as above row 5 elapsed: 78.125 total: 468.75 same as above Logout elapsed: 0 total: 468.75 Acct.Logout()

从上面的结果看起来像:

当地访问时:

mv.net需要几毫秒来创建和注销一个帐户,每个FileOpen调用都很快。

远程访问时:

mv.net花了0倍时间来创建和注销帐户(重用共享帐户?),但每次FileOpen调用都很慢。

如何使远程性能与本地性能保持一致?是否有对mv.net或iis设置进行更改? 当本地和远程调用iis时,用户权限是否有所不同?

任何帮助表示赞赏

2 个答案:

答案 0 :(得分:1)

我认为您的帐户个人资料已配置为相当快速的终止。因此,当您在本地进行测试时,您会多次点击它并且看起来很快。然后你开始使用远程连接,在此期间与D3的连接终止。然后你进行连接,它必须再次登录到D3,导致性能下降。

我的建议是将帐户资料设置为不在注销时终止。因此,在该点处命中它的所有连接将使用相同的持久会话。您的本地连接将终止,然后当远程连接进入时,D3的登录会话仍将处于活动状态,您不会感到新登录的痛苦。如果那不是它,请告诉我,我们将通过它。 :)

答案 1 :(得分:0)

我在今年早些时候的上一份工作中遇到了同样的问题。在那里,IIS与BlueFinity Session and License Managers在单独的服务器上。此外,Pick系统是D3。我们观察到的是,托管会话管理器和许可证管理器的计算机具有最佳的响应时间,而其他任何服务器的响应时间都长2倍。将会话和许可证管理器移至IIS服务器为该服务器提高了速度。将它们移动到另一台服务器可以提高该服务器的速度。确实很奇怪,因为所有请求在处理之前都是通过Internet,WAF进入IIS的。

BlueFinity团队观察了我们测试应用程序上的行为,并尝试重新创建但无法创建。他们的测试的主要区别是:

1)我们使用了D3,而他们使用的是jBASE 2)我们使用mv.NET 4.4,而他们使用的是4.5 3)我们使用SSH,他们使用标准的telnet

我知道这并不能真正回答您的问题,但是我没有足够的声誉来发表评论。尽管我不再在该公司任职,但有趣的是,这个问题并不是他们的书架独有的,更多的是与BlueFinity底层的东西有关。不幸的是,找到原因似乎并不在他们的优先事项之列。