Forum Discussion

Kent_Perrier_50's avatar
Kent_Perrier_50
Icon for Nimbostratus rankNimbostratus
Aug 30, 2011

load balancing mediawiki

I have a user group that has a website. A part of their website is a Mediawiki wiki. If you are not logged into their wiki, everything works fine. If you log into the wiki it works as long as you got load balanced to server A. If you were load balanced to server B, the wiki doesn't work. If you hit each server individually, the wiki works fine. This is a straight forward http virtual server with cookie persistence with a 60 minute TTL on the cookie. The PHP session information is stored on an nfs mounted filesystem on the two servers.

 

 

Are there any issues load balancing a Mediawiki site behind an LTM?

 

 

Thanks!

 

 

Kent

 

3 Replies

  • Hi Kent,

     

     

    Are you running into an issue with the load balancing? If so, can you clarify what the problem is?

     

     

    Also, out of curiosity, if the PHP session data is stored in a shared location, why do you need to use persistence on client requests?

     

     

    Aaron
  • I don't know if the problem is with the LTM or not, that is why I am asking if anyone else has seen something like this.

     

     

     

    If you are not logged into their wiki, everything works fine. If you log into the wiki it works as long as you got load balanced to server A. If you were load balanced to server B, the wiki doesn't work. If you hit each server individually, the wiki works fine.

     

     

    This is behavior we are seeing. If its broken going through the LTM, but not broken then hitting the servers directly, then that leads my users and myself to the conclusion that going through the LTM is interfering with something within mediawiki.

     

     

    For clarification, when I say "doesn't work" I mean that after you log in your browser connection times out, you cannot go anywhere.

     

     

    I don't know anything about php and mediawiki, I was just googling for php session information (as I thought that might have something to do with this issue) and learned about the session.save_handler and session.save_path server variables. This could truly be a case of a little information being dangerous.

     

     

    As for why we have persistence enabled on the virtual server, every application we have ever worked with here has required persistence, and we did not see a reason why this one would not be any different.