I have a simple page that’s used to pass session variables from an old ASP/VBScript page to a newer ASPX/VB page:
asptonetconn.asp
<%@ Language=VBScript %>
<%
' We grab all the session variable names/values and stick them in a form
' and then we submit the form to our receiving ASP.NET page (ASPNETPage1.aspx)...
Session("DestPage") = "/" & Request.QueryString("dest")
Response.Write("<form name=t id=t action=netfromaspconn.aspx method=post >")
For Each Item In Session.Contents
Response.Write("<input type=hidden name=" & Item)
Response.Write( " value=" & Session.Contents(item) & " >")
Next
Response.Write("</form>")
Response.Write("<script>t.submit();</script>")
%>
From there, it goes to:
netfromaspconn.aspx
<%@ Page Language="VB" %>
<script runat=server>
' We iterate through the Form collection and assign the names and values
' to ASP.NET session variables! We have another Session Variable, "DestPage"
' that tells us where to go after taking care of our business...
Private Sub Page_Load(sender As Object, e As System.EventArgs)
For i As Integer = 0 To Request.Form.Count - 1
Session(Request.Form.GetKey(i)) = Request.Form(i).ToString()
Next
[...other functional code...]
End Sub
</script>
We just recently moved this site to a new server. Before the move, this "hand-off" was virtually instantaneous and the user hardly, if ever, saw anything about either of these files. Now, however, it’s taking 40+ seconds each time the navigation has to go through this process (which, unfortunately, is fairly frequently until I have the time to rebuild the "front" pages). Thankfully, it does get through and pass everything from one "side" to the other, but I can’t figure out what’s taking it so long.
When I look at the browser’s address bar while I’m waiting, it seems to be hanging on the asptonetconn.asp file because, once it navigates to the netfromaspconn.aspx page, everything snaps into place and I never actually see that page show up. To diagnose the issue, I’ve sprinkled in some Response.Write() statements in the asptonetconn.asp file to try and determine what, specifically, is causing the "hang", but they all seem to write to the page immediately. Also, it doesn’t seem to matter what value I send to Request.QueryString("dest"). It always takes around 43 seconds.
Based on all of my testing, it seems like the problem is that last line is just taking forever to submit() the form. Since this is the exact same code as was on the other server, I can’t imagine why this would be a problem. Could someone help point me in the right direction? It’s necessary that these Session values are passed from the older page to the newer, but I’m open to other means of achieving that goal.
2
Answers
It appears that you are experiencing a delay when submitting the form from the asptonetconn.asp page to the netfromaspconn.aspx page after migrating your site to a new server. This delay was not present on the previous server. To troubleshoot the issue, we need to consider a few possibilities.
First, it’s worth checking the network connectivity and latency between the client’s browser and the new server. Slow network connections can introduce delays, so ensuring a stable and fast network connection is important.
Next, compare the server configurations between the old and new servers. Check for any differences in settings related to session management, such as session timeout values or resource allocation for handling sessions. Any discrepancies could potentially cause delays in processing the form.
Additionally, verify the configuration of the ASP.NET application pool hosting the netfromaspconn.aspx page. Make sure it is properly configured and has adequate resources allocated to handle incoming requests. It’s worth checking if there are any specific limitations or restrictions in place that could be causing the delay.
To gain more insight into the issue, enable detailed logging and debugging in both the ASP and ASP.NET applications. This will allow you to track the execution steps and timestamps in both pages, helping you identify the specific point where the delay occurs. Reviewing the logs might reveal any errors or warnings that could be causing the delay.
Consider using performance profiling tools to analyze the execution of both the ASP and ASP.NET pages. These tools can help identify potential bottlenecks, such as slow database queries, excessive file I/O, or resource-intensive operations.
If the issue persists, it may be worth considering alternative approaches for passing session variables between the old and new pages. Options include using cookies, URL parameters, server-side caching, or storing the data in a shared database or cache.
By following these suggestions and investigating the various aspects of your setup, you should be able to pinpoint the source of the delay and take appropriate measures to address it.
Are you using SQL server to manage the session(s)?
Its possible that the new site has a different or much slower connection to the database server.
As a result, then with SQL sessions, then time to "serialize" the data, and save into SQL server session state management is taking a long time.
I would check and test in web.config, and change session management with "in-proc" sessions to see if this is the issue. Do this as a test, or so called proof of concept.
If using in-proc removes the delay, then that’s your issue.
While SQL managed sessions can be rather slow, it not all that noticeable when the SQL server is on the same web server, or at least you have a very good connection to SQL server from the web site.
Often in these migrations, you wind up say moving the web site to some cloud server (not on premises anymore), however then some VPN was setup to continue to say use SQL server that is still "on-site" at company location.
This setup will of course cause a VAST slow down in SQL server performance. While most data pulls etc. are rather small, the payload for session state management can become quite large, and put more stress on SQL server, which in turn with say a VPN connection to SQL server? That is a really huge drop in SQL server performance that occurs if say a VPN to SQL server has occurred here.
So, try in-proc session management, and see if that helps.
Unfortunately, in-proc session management while fast, it not all that reliable and robust. You might have to consider moving the current location of the database server as a possible fix here.