fats Posted June 2, 2009 Share Posted June 2, 2009 Hey people, I've got this weird problem (yea I know, they all seem weird in the beginning ;-)). We've got about 130 customers using our website through HTTPS, loging in and maintaining the authentication through a session cookie. Two of those customers have a problem where randomly for certain machines in their networks (also randomly which machines they are) lock up from time to time making a request to our website. Any subsequent requests also hang and sometimes the requests even time-out, but most often all requests suddenly get on with what they were doing after 10 or 30 or 60 seconds or so. Now, I've added error_log statements for debugging purposes and it appears that the requests actually do reach our web server but they hang in the session_start() method in our index page. Does anyone have a clue on why this happens? Note that the other 128 users (offices) don't experience this problem at all and I cannot reproduce it within our local network either. When I move my laptop to their office, it's quite easy to reproduce by sending a couple of requests (though occasionally it's hard to reproduce). Some more information: 1. Server info: PHP 4.4.7, FreeBSD 6.2-STABLE, Apache (release 10337100) 2. We've tried two ADSL modems client-side, one of which being a Zyxel. Pluged my laptop directly into the modem to omit patch panels and a switch. Reproduceable on both ADSL modems (forgot the brand of the other one). 3. Reproduceable on any client (Firefox, IE, Safari, Chrome) and on both Windows and Linux. 4. Our hosting provider says it can't find anything unusual in their logs whenever I reproduce the hang. They do state that during a hang the server seems to send packets to the client which do not seem to be answered (no traffic at all from the client during the hang). But it's hard to tell what these packets are, if they require an answer at all and if they're all the same as we're using HTTPS. Any thoughts? Quote Link to comment Share on other sites More sharing options...
gizmola Posted June 2, 2009 Share Posted June 2, 2009 Why aren't you using php 5? Quote Link to comment Share on other sites More sharing options...
fats Posted June 2, 2009 Author Share Posted June 2, 2009 Why aren't you using php 5? Good question, working on it, moving to a new server with PHP 5 installed. Quote Link to comment Share on other sites More sharing options...
gizmola Posted June 2, 2009 Share Posted June 2, 2009 Since there's so much that's improved there, I'd suggest you guys focus on the upgrade and see if that fixes the problem. Quote Link to comment Share on other sites More sharing options...
fats Posted June 2, 2009 Author Share Posted June 2, 2009 Since there's so much that's improved there, I'd suggest you guys focus on the upgrade and see if that fixes the problem. I'm starting to think you're right on this. The problem is making me pulling my hair out and we're late with the move to the other server mainly due to this problem. So thanks for your reply, I'm seriously considering speeding up the move to the new server. However, if anyone has an idea why this happens, please do tell as it's not certain if a PHP upgrade will solve this issue. Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted June 2, 2009 Share Posted June 2, 2009 Set up a test page on the same site that strips out everything: no SSL, no sessions, nothing fancy. Try and reproduce the problem. If the problem can't be reproduced, then slowly start introducing elements of your application back into it. Add the sessions. Add the SSL. Until it starts happening again. Also, see if you can't record the packets sent from the client machine and the packets received for this test page. Make sure that you aren't experiencing extremely high packet loss. It could be that one side is not catching all of the packets so the sender has to repeatedly send them (if that is indeed how networking works). It could just be that these few clients or users have bad networking environments or extra firewall rules or something somewhere that is preventing full throughput of the traffic. If that's the case no amount of PHP upgrading will help you. Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted June 3, 2009 Share Posted June 3, 2009 Does the page(s) that "hang" access the same session data file more than once? For example, using frames/iframes or an image script that uses the session and the main page also uses the session? The symptom sounds like session data file locking when one visitor makes multiple requests that access his session data file while it is already locked by a different portion of the script that makes up the page. Quote Link to comment Share on other sites More sharing options...
fats Posted June 29, 2009 Author Share Posted June 29, 2009 Hey people, We eventually decided to let a network expert (Netdialog) look at the problem. The problem seems to be that quite regularly an echo statement hangs due to a connection problem between the server and the client. And of course, when this echo hangs, the session does as well and any further requests from the same client will have to wait until this connection is released again. It seems to be quite hard to determine the exact location of the problem, but they think it's with the ISP. For now, we decided to buffer all output and release the session before sending it to the client. Although it doesn't take away the problem entirely, our customer is satisfied for now. Thanks for your help and suggestions. Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted June 29, 2009 Share Posted June 29, 2009 If you ever get this entirely resolved could you please remember to update this thread with the problem and solution. I like to tuck little tidbits of experience like this away for future reference. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.