Da virksomheden skal loadbalancere serveren, implementerer webprojektet én på hver af de to front-end servere (web1 og web2). Men sessioner bruges i projekter. Når du først lander på web1, er det muligt at hoppe fra web1 til web2, fordi belastningen kan stige efter web1. Jeg fandt en masse information på internettet, og jeg forstår også konfigurationen i web.config <sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" timeout="30" cookieless="AutoDetect" /> Mange eksempler på internettet er stateConnectionString="tcpip=127.0.0.1:42424", hvilket selvfølgelig er fint på en webserver, men når du ændrer stateConnectionString til stateConnectionString="tcpip=192.168.1.82: 42424", vil der opstå problemer med begge frontends. Microsoft gav ikke en specifik løsning, og eksemplerne på MSDN peger også på 127.0.0.1. Senere, efter at have undersøgt og konsulteret eksperter, indså jeg, at jeg var nødt til at ændre registreringsdatabasen for serveren, der gemmer Sessin; her er den 192.168.1.82, og ændringen er som følger: Ændr registreringsdatabasen:
HKEY_LOCAL_MACHINE"SYSTEM"CurrentControlSet"Services"aspnet_state"Parametre
AllowRemoteConnection=1
Genstart derefter ASP.NET State Service
Forbindelseskonfigurationen er som følger:
<sessionState mode="StateServer" stateConnectionString="tcpip=192.168.1.200:42424" cookieless="AutoDetect" timeout="60" />
Efter det var det okay efter testen. Håber det hjælper andre. Der er et andet problem, som jeg stadig ikke forstår. WAP-siden, jeg lavede, vil have dataene gemt i ViewState på siden, og når siden konstant opdateres, vil dataene i den gå tabt, og tiden vil aldrig overstige 20 minutter. Jeg ved ikke, om det er en fejl fra Microsoft eller hvad, dette problem optræder ikke på websider. Løsning. Efter en periode med udforskning er det bedst at bruge mindre viewstate på WAP-siden, og hvis asp.net state-tjenesten er aktiveret, er det bedst at sætte cookieless til true, ellers går sessionen tabt. |