MV.NET calls much slower when website accessed remotely vs locally

Question

I have an asp.net webforms page that makes calls to pick/d3 through mv.net. I've logged the server side performance by surrounding the mv.net calls with timing code, for example: logTimeElapsed() getDataFromPick() 'gets 5 rows of test data logTimeElapsed()

When I call this page from the hosting iis server, I get quick response times such as: 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()

However, when I call this same page from another location on the network or on the web, I get response times that are roughly 7 times longer: 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()

From the results above it looks like:

When Accessed Locally:

mv.net is taking a couple milliseconds to create and logout of an account and each FileOpen call is fast.

When Access Remotely:

mv.net is taking 0 time to create and logout of an account(reusing a shared account?), but each FileOpen call is slow.

How can I bring the remote performance in line with the local performance? Are there changes to the mv.net or iis setup to make?
Is there something going on with user permissions that is different when iis is called locally vs remotely?

Any help appreciated

Answer 1

I'm thinking your account profile is configured for a fairly rapid termination. So when you're testing locally you hit it a few times and it looks fast. Then you gear up to use a remote connection, during this time the connection to D3 terminates. Then you do the connection and it has to login to D3 again, incurring a performance hit.

My suggestion is to set the account profile to not terminate on logout. So all connections hitting it at that point will use the same persistent session. Your local connection will terminate and then when the remote connection comes in, the login session with D3 will still be active and you won't feel the pain of a new login. If that's Not it, let me know and we'll work it through. :)

Answer 2

I encountered the same issue at a previous job earlier this year. There, IIS was on a separate server from the BlueFinity Session and License Managers. Additionally, the Pick system was D3. What we observed was that the machine that hosted the Session and License Managers had the best response times, and any other server experienced response times that were 2x longer. Moving the Session and License Managers to the IIS server brought the increased speed to that server; moving them to another server brought the speed to that server. Strange indeed because all of the requests were going out through the internet, through the WAF and into IIS before being processed.

The BlueFinity team observed the behavior on our test application and attempted to recreate but were unable. The main differences in their tests:

1) We used D3 and they were using jBASE 2) We used mv.NET 4.4 and they were using 4.5 3) We used SSH and they used standard telnet

I'm aware this doesn't really answer your question but I don't have enough reputation yet to leave a comment. Though I am no longer with that company, it is interesting to note that this issue was not unique to their stack and more to do with something likely beneath the surface with BlueFinity. Unfortunately, finding the cause did not seem to be high on their list of priorities.