losing sessions when running in StateServer mode
in [ASP .NET]
|
Prev: System.Web.IHttpHandler, System.Web.SessionState.IRequiresSess
Next: Looking for a NNTP server that discuss csharp/.net
From: 3P on 23 Jul 2010 10:07 >> SQL Server state is a whole lot slower. Never used it myself. > > I have used it in a couple of shops. It was OK, and I didn't really see > any performance issues using a SQL State server. >> >> If you had been following the thread closely you will have seen that >> the problem turns out to be that the session-id is being lost. >> (Session-id is not itself stored in the session.) If the session-id is >> being lost then this will affect any session regardless of the >> mechanism used to main it (in-proc, state or sql server). If you can >> suggest how the OP might investigate the cause of this then that would >> be helpful. > Because that was small app. It is a lot slower. And it doesn't scale well. MS words if You don't believe me. You can make it work a bit faster if You turn off session on pages that doesn't need it or set read only session access mode. On large app You will probably have to write custom code and use many session databases on many servers.
From: Brian Cryer on 23 Jul 2010 12:45 "JK" <JK(a)invalid.com> wrote in message news:4c495831$0$2963$ba4acef3(a)reader.news.orange.fr... > Brian Cryer a �crit : >> >> My feeling is that either: >> 1. Its an application issue - something is explictly changing the session >> ID or the cookie ("ASP.NET_SessionId" I think) that .NET uses to keep >> track of the session ID. > > Right! I've found a hack in the code trying to set the timeout for this > cookie. I've removed it and it seems better so far. I'm still testing. > > Many thanks for all Brian Well done for finding it. Thank you posting back. -- Brian Cryer http://www.cryer.co.uk/brian
From: "Mr. Arnold" MR. on 23 Jul 2010 12:47 "3P" <nospam(a)serwer.pl> wrote in message news:op.vgaubq1qmsp0fz(a)mcs... >> It was an async thread with no return. So the pages were not waiting >> for a return, which was using an async WCF Web service on the back-end, >> a Web service farm. There were no performance issues. The main point was >> to get the object back into session if it was lost -- no matter what >> caused the session to be lost with IIS resets being done 5 to 6 times >> throughout the day, which was used worldwide 24/7. It was a critical >> application within the enterprise level solution, but it was not a high >> usage application within the total enterprise solution. > > Well every thread is async. > > I know page wasn't waiting for thread to finish, but still two worker > threads > were used for every page load/unload. But You said it wasn't high usage > app. That's > probably why You didn't see performance penalty. I don't think it would have made a difference if it was a high usage app for the simple fact that it was using an async WCF Web service to persist the serialized object on the back-end. It was used often enough along with another application within the solution that was using the same type of technology.
From: "Mr. Arnold" MR. on 23 Jul 2010 12:54 "3P" <nospam(a)serwer.pl> wrote in message news:op.vgaq2aulmsp0fz(a)mcs... > > Now I know for sure. You are plain dumb. I kindly asked and You are > attacking me. I am not here to hold your hand nor did you work on the project. Those are the facts that can't be ignored. > > And BTW this is very ugly solution. You don't know a lot about ASP.NET as > You shown in this thread. Yeah right!!!!!! And I am sure you no nothing about OOP, ASP.NET WCF Web services and ADO.NET Entity Framework used in n-tier technology. :)
From: "Mr. Arnold" MR. on 23 Jul 2010 13:00
"3P" <nospam(a)serwer.pl> wrote in message news:op.vgauvgshmsp0fz(a)mcs... > >>> SQL Server state is a whole lot slower. Never used it myself. >> >> I have used it in a couple of shops. It was OK, and I didn't really see >> any performance issues using a SQL State server. >>> >>> If you had been following the thread closely you will have seen that >>> the problem turns out to be that the session-id is being lost. >>> (Session-id is not itself stored in the session.) If the session-id is >>> being lost then this will affect any session regardless of the >>> mechanism used to main it (in-proc, state or sql server). If you can >>> suggest how the OP might investigate the cause of this then that would >>> be helpful. >> > Because that was small app. It is a lot slower. And it doesn't scale well. > MS words > if You don't believe me. Here you go projecting again I see. > > You can make it work a bit faster if You turn off session on pages that > doesn't need it or set read only session access mode. Like all pages need session? > On large app You will probably have to write > custom code and use many session databases on many servers. I don't believe you. |