Hang probleem website <niet consequent>

[Verwijderd]

We hebben een probleem met onze website en dat is dat hij op verschillende momenten blijft hangen na het klikken op een link. Wanneer we vervolgens de browser sluiten en de pagina opnieuw openen en wederom op de link klikken staat de pagina er direct.

Het is echt niet altijd dat we deze routine moeten uitvoeren. In veel gevallen staat alles er direct en werkt alles naar behoren. Het is ook niet zo dat het probleem zich voordoet op vaste tijdstippen en vaste links. De ene keer is het link a en de andere keer link c waarbij het probleem zich voordoet, en zoals eerder het kan ook zo zijn dat het probleem helemaal niet komt.

De gebruikte technieken voor het ontwikkelen van de website zijn:
- PHP Version 5.2.0
- Apache Release 10337100
- Apache API Version 19990320
- PEAR <PHP implementation of the XML-RPC protocol>

Er wordt gebruik gemaakt van twee servers, een database server en een client <website>. De gegevens die van de server opgehaald worden die worden tijdelijk opgeslagen op de website voor zoveel uur.

We hebben reeds metingen gedaan voor het ophalen en opslaan van de data, dus de connectie testen tussen de servers, en dit ging snel. We hebben dus het vermoeden dat het probleem hier niet in zit.

Het vreemde is dus dat de pagina de ene keer binnen 1 seconden er staat en de andere constateren we het hang probleem.

Heeft iemand enig idee of heeft hij een keer hetzelfde probleem gehad en belangrijker hoe kunnen we het oplossen. We zijn ook bezig met een tijd meter te installeren dus na ieder script kunnen zien hoe lang hij daarover gedaan heeft. We hopen hiermee een oplossing te kunnen vinden. Heeft er iemand nog andere tips voor ons?

[Verwijderd]

wat hangt er precies als je op een link klikt? Of krijg je gewoon een witte pagina terug ipv de pagina die je moet hebben?

[NMe]

Komt dit in elke browser en op elke pc voor? Of alleen op één testsysteem in één browser?

[Verwijderd]

Ik moet bijvoorbeeld 30 seconden wachten, op dat moment komt wel de goede pagina op het scherm maar duurt gewoon echt heel lang. 30 seconden is lang dan.

Het gebeurd in iedere browser en op meerdere pc's.

Ik ben een beetje met tijd waarneming gaan puzzelen in in het complete systeem ingebouwd en het lijkt te gebeuren op het commando

session_start()

Ik heb alles gecontroleerd en roep deze functie toch echt maar een keer aan.

[Genoil]

Is het altijd 30 seconden? Dan is het ws. een of andere oneindelijke loop waarin PHP er na 30 seconden mee stopt.

En zoals je zelf al aangeeft heeft het iets met de sessie te maken, want zodra je je browser een keer gesloten hebt is je sessie ook weg. Ik zou je sessie data controleren en dan met name de punten waarop deze data wordt gebruikt in loops.

Is het zo dat als je het probleem 1 keer hebt gehad, en je dan een andere link volgt (zonder eerst browser te sluiten), je weer hetzelfde probleem hebt of is dat ook weer willekeurig?

[Verwijderd]

Het is niet altijd 30 seconden, soms ook 120 seconden (max) maar het kan daar ook tussen schommelen.

De data is niets mee aan de hand want het gebeurd echt op de session_start, er wordt dus nog geen script aangeroepen met de vars in de session.

Het is dus echt direct op het commando.

Ik heb namelijk een timer_start ervoor gezet en een timer_stop erna en dan zie ik die tijd.

[Woef]

He interessant topic. Ik heb hetzelfde probleem en merk dus ook dat het gebeurd bij session_start();.
Apache log geeft dan ook het volgende aan;

code:

(OS 64)The specified network name is no longer available.  : winnt_accept: Asynchronous AcceptEx failed.

Naar mijn idee ligt het niet aan de configuratie. Het gebeurd zowel lokaal als bij een gerenomeerd hosting bedrijf.

[Verwijderd]

ik heb de applicatie inmiddels ook op een andere server getest en daar heeft het probleem zich niet voor gedaan.

Ik heb dus toch het idee dat het ergens in de configuratie van de server zit.

De systemen zijn trouwens allemaal linux en geen windows.

[Verwijderd]

30 (of misschien 45) klinkt als een DNS timeout. Staat de netwerk configuratie wel goed? Netmasks etc.

Je kunt bv de daemon eens tracen met trace. Of als je Solaris gebruikte, truss of nog veel mooier dtrace, lockstat etc.

[Verwijderd]

hmm, ik zal daar eens naar gaan kijken.

Ik heb echter ook het commando session_start eruit gehaald en toen liep de applicatie echter goed door.

[[ti]]

Als een gebruiker twee pagina's tegelijk opvraagt dan zal de 2e session_start() wachten tot de lock op de session file weg is. Je kunt dit voorkomen door session_write_close() te gebruiken nadat je klaar bent met wijzigingen in de sessie data.

[Verwijderd]

ga ik nogmaals proberen, had ik namelijk al keertje gedaan maar zal hem eens terug zetten.
ik heb echter ook de session_start gemaakt in een if

if (session_id() == "") session_start

anders loopt hij nog en hoef je niet eens te starten

session_write_close() heb ik er ook ingezet maar lost het probleem ook niet op

[ Voor 14% gewijzigd door Verwijderd op 11-12-2006 13:56 ]

[Woef]

[PHP] Gelockte session blijft hangen
Hier is een topic over hetzelfde probleem alleen daar is dus ook geen oplossing gevonden.
Ik ga nu de session_write_close() proberen.

[Verwijderd]

Ik heb nogmaals geprobeerd die session_write_close te gebruiken.

Dus in mijn session class na iedere get or set de session zo weer proberen te sluiten.

Het lost in mijn geval niets op.

Is het bij andere wel gelukt met de session write close

[Verwijderd]

ik heb reeds gebeld met een aantal gerenomeerde bedrijven om het probleem op te lossen maar niemand kan echt een directe oplossing geven.

We kreeg ik een tip om het eventueel op database of shared memory nivo te doen.

Helaas is db geen optie voor ons en shared memory lees ik slechte reviews over.

Heeft er iemand meer ervaring met shared memory?

Ik hoor het graag....

[Mac_Cain13]

Als de session_start() er zelf lang over doet en je zeker weet dat dit niet komt doordat de sessiefile gelockt is. Lijkt het mij mogelijk dat het ophalen van de sessiefile traag gaat. Ook omdat je zegt dat het op een andere server wel goed gaat zou het kunnen dat het op een lager nivo zit of in de PHP config zelf.

Werken sessies in andere scripts op dezelfde server wel vlekkeloos? En heb je al eens gekeken waar je sessionfiles staan en of er daar niet iets mis is? Als je (bijvoorbeeld) een beschadigde HDD zou hebben die er soms 20 seconden over doet om een sessionfile te lezen zit je daar op te wachten.

Ik zou in ieder geval eens kijken of het niet aan dit soort dingen kan liggen. Aangezien de site op een andere server wel perfect lijkt te werken en je je config en dergelijke (neem ik aan) al door hebt gespit.

[Verwijderd]

ik heb alles al aardig doorgespit, ook samen met de server beheerder.

ik heb nu de callback functions gebruikt van php waarbij ik dus zelf de session file in een directory open en sluit met eigen functies.

het lijkt er nu goed op te gaan. Ik heb 10 minuutjes aan het klikken geweest en nog geen probleem tegen gekomen.

nu alleen nog zorgen dat de session files ook een keertje netjes opgeruimd gaan worden, anders wordt die directory wel erg vol.

[Verwijderd]

ik kan nu met een gerust hard zeggen dat het opgelost is!

De sessie blijft niet meer hangen, ik heb het met de callback functions opgelost!

[Mac_Cain13]

Mooi dat je het hebt weten te fixen! Weet je misschien ook wat exacter waar het hem in zat? Misschien dat iemand dan later ook nog wat aan deze informatie heeft.

Wat doe je bijvoorbeeld anders in je callback-functie dan PHP standaard zou doen, of dat je in een eerdere callback-functie poging hebt gedaan?

[Verwijderd]

Wat ik anders doe als php is naar mijn idee niets.
Ik open gewoon een file en schrijf de gegevens daarnaar toe, daarna sluiten.
Met ophalen is het openen lezen en sluiten weer.

Waar het probleem precies in zat zijn we nog aan het vast stellen. Ik weet dat het op session_start zat. Maar waar het in de routine bij php fout zat durf ik niet te zeggen.

De callback functies heb ik van php.net en aangepast aan onze code en dergelijke.
Verder is het op file nivo en niet op database nivo omdat dat niet mogelijk was in onze situatie.

[MisterData]

Misschien dat jouw callbacks de bestanden minder locken en dat PHP op de een of andere manier in z'n eigen locks blijft hangen (die dingen kunnen natuurlijk ook een timeout hebben)?

[Verwijderd]

ja daar heb ik ook al aan zitten denken.

Ik ben blij dat het voorlopig in ieder opgelost is, ik zou niet weten hoe je die session_start anders moet gaan debuggen