1

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

Jim B
  • 420
  • 3
  • 10
  • Side comment: I know you're trying to solve a specific problem here, so maybe this is out of line: Multiple `Acct.FileOpen("...").ReadV()` operations create more work on the server as well as making the connection much more chatty (increasing transaction time). I'd recommend a single FileOpen followed by one or more read operations off that object. You can retrieve specific attributes in a single mvItem read using names or atb references, so you may get what you want in a single statement rather than several, and without putting the entire item on the wire from D3 when you don't need it. HTH – TonyG May 07 '16 at 00:45

2 Answers2

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. :)

TonyG
  • 1,432
  • 12
  • 31
  • I'll look into this now. For more info, here is a response that a collegue got back from BlueFinity: _What other people have done in circumstances like this is to use packet sniffers (Wireshark, for example) on the network to diagnose the problem, because it is not mv.NET. It has to do with some network layer issue that is giving poor telnet performance, which is then impacting mv.NET performance._ – Jim B May 03 '16 at 20:23
  • Thanks Tony, We looked at the account profile and it is setup for 'no auto terminating' and 'no auto free-up'. Also when I compare the mv.net connection monitor logging on the iis machine when the site is remotely and locally called, it has the same info logged and the same client id (MachineName:W3Wp.exe:6112). – Jim B May 04 '16 at 17:02
  • 1
    It seems Bluefinity isn't understanding the details yet. To be clear, I'd like to recap my understanding too: You have one session manager with a single (?) persistent Telnet (MVSP?) connection to D3. I'm guessing it's on the same box running IIS (?). You are using a localhost browser, hitting that IIS and getting one timing. You hit that same server, ASPX, DLL, web.config from another PC or from outside the network and you get different timing. You can do this alternately and see the exact same weird results. All correct? Interesting challenge. I'll keep an eye here for your response. – TonyG May 05 '16 at 05:18
  • 1
    The connection from the service to D3 isn't going to change based on the client to the service. So the issue must be from your code in IIS to the service, which then proxies to D3. In your mvAccount instantiation, or in web.config, are you using a host name or an IP address? I'm wondering if a DNS is involved. With each request from IIS to the socket server there might be a hostname resolution - shouldn't be, but might be. And while it shouldn't be different between local and remote client, IIS might do something different there. Try using an IP address to get to the session manager service. – TonyG May 05 '16 at 05:45
  • Yes, you have the details right in your recap, with a couple of small (inconsequential I think) differences. We have one session manager with **2** persistent telnet connections to D3. And yes it is on the same box running IIS. And yes I can do this repeatedly and see the behavior alternate depending on whether its hit from the local machine or a different machine. Only one connection ever gets used, since I'm the only one testing the site. – Jim B May 05 '16 at 21:44
  • 1
    IIS apps run in an Application Pool. Pools have permissions. I wonder if you're hitting a different application pool with `http://localhost/app` than with `http://foo.tld/app`. If so there may be extra security checks as mv.NET makes each (localhost) network call (.NET Remoting?) to the manager service. The security for a local request may be more lax than for a remote request - each remote request might incur an authorization check which simply takes time. I don't know how to test that theory, I hope you can run with it. Bluefinity may be right about a network layer, but not one over Telnet. – TonyG May 06 '16 at 09:02
  • Not yet. I tried displaying the app pool (`System.Security.Principal.WindowsIdentity.GetCurrent().Name`) and it shows the same when called locally and remotely. – Jim B May 20 '16 at 19:08
  • 1
    I'll think on this for a bit. You did check the Windows Identity, which is what I suggested. But for grins, please check the specific [app pool](http://stackoverflow.com/questions/25664278/how-to-get-application-pool-name-through-code-c-asp-net), just in case it's set for a different kind of authentication. – TonyG May 23 '16 at 16:37
  • Hi Tony, I could be wrong, but I believe the call to System.Security.Principal.WindowsIdentity.GetCurrent().Name is showing the app pool. When run locally or remotely it displays "test-app-pool" which is an app pool I created and assigned to the web application. I then set the app pool to ASP.NET v4.0 in IIS and reran the page and got IIS APPPOOL\ASP.NET v4.0 for both local and remote. Jim – Jim B May 24 '16 at 20:26
  • I tried getting the app pool with the method you suggested, but could not reference the Microsoft.Web.Administration.ApplicationPoolName property. That property is not there. I've also tried the method suggested by p0nkie [here](http://stackoverflow.com/questions/10101162/get-the-application-pool-identity-programmatically), but am bogged down with permissions issues. More info: I also enabled trace on the application and there were no significant differences in the results for local and remote. – Jim B May 24 '16 at 20:41
  • As discussed in email, my suggestion at THIS point would be to replace the telnet pipe with MVSP. If there *is* a difference, and I'd be very surprised, then the issue is in the telnet connection, probably with some hangup in a reverse DNS call. If there is *no* change then I'd suspect something in mv.NET, even though at that tier they are unaware of the ultiate client. If they don't help trace that, there's probably nothing else we can do. Tracing into mv.NET will affect the issue being tested. So until something else comes up, I'm signing off of this one. Sorry. – TonyG May 26 '16 at 00:55
0

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.

Mike Wright
  • 502
  • 4
  • 13