Forum

Hi Hugo,

I was trying to see how the php-fcgi load balancer works. I added multiple servers to the php-fcgi.conf file and started the php-fcgi daemon. Checked the "ps auxf" and it shows multiple instances of php-fcgi running on different ports. I also modified the fastcgi section of httpd.conf to connect to these multiple fcgi connections.

How can I measure or see some kind of log of what is happening to my requests and how they are being load balanced.

Hiawatha version: 6.14
Operating System: Ubuntu 9.04

Hugo .. did you miss this thread? I am very interested in learning these things. Also, if you can give a short write up of how to run this multiple servers distributed from other machines, that would be great too.

No, didn't miss it. Just forgot to reply

When you start testing the load balancing feature, don't forget one thing. It is possible that every FastCGI daemon is running on it's own server. So, every daemon has it's own directory with session records. To prevent client session from getting disrupted (a client is assigned to another FastCGI daemon which has no knowledge about the clients session), Hiawatha remembers the client's IP address and keeps assigned the same FastCGI daemon for as long as the session lasts. Now you know what the SessionTimeout in a FastCGIserver block does.

So, when you want to test the load balancing feature, make sure you set SessionTimeout to zero. Otherwise, you will be assigned to same FastCGI daemon every time you hit the refresh button.

To test the load balancing, you can give each FastCGI daemon it's own php.ini. Set display_errors in one php.ini to 'On' and to 'Off' in the other one. Create a PHP script which has "print ini_get('display_errors');". Request that script in your browser and keep hitting F5. If the load balancing feature works oke (and it will ) it will keep switching between the value 0 and 1.

Another cool feature you can test is to temporarily kill one FastCGI daemon. Hiawatha will notice that one daemon is no longer available and skip that one. It will check its availability every minute. So, after you restart the killed FastCGI daemon, Hiawatha will automaticly start using it again after a minute.

Thanks Hugo .. again its time for me to sleep. 11:00 PM here. I will try these out and post my findings.

About how to run multiple FastCGI daemons on multiple servers: make sure every server has the same files on disk and have them in the right directory (one that matches the WebsiteRoot settting in the Hiawatha configuration). Best thing to do is to have the PHP servers mount the directory that holds the website code from one server. This way you only have one place where you have to maintain your code and you are sure that all PHP servers are executing the same PHP code.

Can I just run a php-fcgi on multiple machines and use the remote machines IP on the php-fcgi conf of the main server? Also, how do I ask php server to mount and run from a particular directory (remote)? Sorry .. if I am being ignorant.

Yes, that's the whole idea of load balancing. Let multiple servers do the job. Hiawatha does the static files, the PHP servers do the CGI executing. Just install Hiawatha on all servers. On the webserver, start Hiawatha, on the PHP servers start php-fcgi.

You can use several techniques to mount a remote disk. NFS is the most common one. How to use NFS is explained in many HOWTO's on the internet. It will be a waste of time if I'm gonna explain that here.

The best way to get started is to just copy the website code to all servers, the webserver and the PHP servers. Make sure the location of the website is the same on all servers.

Thanks Hugo. I will try this out within a day and get back.

Hey Hugo ... this is great. Thanks a lot for writing the details. I tested this. You can see the result here:
http://me.prit.us/testcgi.php

I am impressed. So if there are few servers that can run simultaneously sharing the load, then the big resource intensive sites running PHP can perform much better.

Now I am installing Hiawatha everywhere. . I just got access to a production VPS, removed apache and installed Hiawatha. My VM's run Hiawatha. Moved my users to Hiawatha now.

Don't forget to change php-fcgi.c with the new version I sent you.

In another topic, you spoke about a website with 300.000 visitors a month. Is that one also going to run on Hiawatha? If so, can you tell me what website it is? I'd like to see how it performs. And is it oke that I link to that site with a message 'this site runs on Hiawatha'?

I am not sure if you were able to see my test in action. I had shutdown the machine. sorry. . Anyway, now its up. The link again - http://me.prit.us/testcgi.php.

Regarding the site that I had mentioned with those many visitors, I am still not sure what the final decision might be. If we move away from Drupal, then there is a chance we might continue using shared hosting in which case I don't have an option to use Hiawatha instead of Apache. But, if we move to a VPS, then I am definitely going with Hiawatha. In this case, you can link to the site and I can ask the leads if I can put a banner in there to your site as well. There will be a decision this month. I will keep you posted.

Yes, I had seen the test script. Looks oke.

I hope you will chose the VPS and run Hiawatha It's also more secure to use a VPS instead of shared hosting. And more flexible, like usage of crontab, which many shared hosters don't allow.

Yeah. VPS is definitely preferred over a shared host. The only factor that we might consider is the associated cost. VPS's are usually expensive and we are an open source community. We are trying to stop using ads. If we have the ads, we might be able to afford the VPS. Lets see how it goes.

I'm curious about the website and the open source community. Can you tell me something about it? Can you give me the URL of the website?

I thought you must have guessed it. - http://puppylinux.org

Well, you only said you were using Puppy, not that you are part of that community. Nevertheless, cool! If it switches to Hiawatha, it will be a big contribution to my 'users list'!

I am sure many folks in the community love Hiawatha even if they may not have used it. I read posts on how users were switching from Apache to Hiawatha. I hope that we can run the community site on Hiawatha as well.

One of the test websites I was trying to run Drupal on Hiawatha was for testing our community site. You can see this here as well. This is running on a VPS with Hiawatha. - http://puppybiz.prit.us. The links will be changed if we decide to continue here.

Looked for Puppy on distrowatch. It's the number 8 distro! Cool. Expected it to be lower on the list. A switch would really be good for Hiawatha!

I can say this about Puppy - "Once you try Puppy, you will be hooked". The distribution has the capability to bring back to life old and throw away type of systems. It is only 100MB and runs fully from RAM if it gets 256MB. I have a $50 laptop that has 128MB RAM with no hard disk. Puppy runs on it. Its actually amazing. Very responsive.

I and one other community member have a distro based on Puppy (adding / changing some default Puppy stuff) - its called Macpup - http://macpup.org. We recently got on distrowatch for the first time. It may not be on the main charts yet.

Hugo ... I have couple of questions.

1 - If each php-fcgi daemon server needs the data to be present on its own server machine, does it also need the mysql data on each site as well (if the site is using mysql)?

2 - Also, if we use NFS and mount from multiple clients. Will the NFS server usage overshadow any savings or performance increase we get by distributing the load of php-cgi?

1) You can of course have MySQL installed on a seperate server to which all the PHP servers connect. If your website doesn't contain many static files (images, CSS, etc), the load of your webserver might be low enough to also serve as a MySQL server.

2) Good point, that is very well possible. It all depends on the speed of file server (HDD speed) and the connections to it. It just a matter of good testing. Don't forget that modern OSes are capable of caching files that are used frequently. Increasing that internal cache might do wonders.

Thanks Hugo. For MySQL apps, the apps would then need to point to the central MySQL server.