I am trying to balance the load from my main server to a few other servers. To do this, I am moving a high traffic script to another server. However, I want this change to be unknown to both visitors and spiders. This is a solution I have worked out:

Server A (main server)
Server B (script execution / stores and executes php scripts)

So, server A gets a visitor. It uses a php include to execute a script on server B. Server B does the work of actually querying the database, parsing the data, and serving the page to server A. Server A includes the file generated by server B, and displays it for the user.

Here is my question:

Under high loads of visitors and spiders, will this solution help relieve the load on the main server?

No, it won't. Until you query the DB on every request it doesnt matter where the heavy script is located. You should either optimize your DB or implement some file cache for those results which are changed rarely or use both approaches.

I believe you are wrong on your assumption that by including a file on a different server, you can spread the load to multiple servers. It is simply including a file, the one server that the user is actually hitting will do the processing regardless.

In that case, is there a way to get the second server to do the processing, and serve up the html page to the originating server?

I think if you had a web site utilizing frames, you could have one frame source directed to server #1 and the other frame source directed to server #2. This might not work for your situation but conceptually speaking it will accomplish what you are asking.

I will repeat once again. If your data in your database is being changed significantly more rare than requested (and it is true in 95% cases) you can generate static html pages or cache your data into flat files somehow instead of pulling the same results every time from database.

If you have physical access on both servers and they are in the same place, you can make a 'server farm'. That will definitely reduce the load to both of them, as the data will be processed (and served) by two servers at the same time.

But can actually reduce the load even without the above method. You can use as well server b for db quering (and data processing), and have server a just to serve the pages. Which means, just to show the wanted content to the viewer.

mtishetsky, when we talk about php, we mean that we are going to have a dynamic web page, right? (well, at least in most cases). If the content changes dynamically, using static html pages will lead you nowhere. When a record is added to the db the page probably won't be updated..

Originally Posted by Spiros

mtishetsky, when we talk about php, we mean that we are going to have a dynamic web page, right? (well, at least in most cases). If the content changes dynamically, using static html pages will lead you nowhere. When a record is added to the db the page probably won't be updated..

When we talk about dynamic webpages we don't mean that a page should be absolutely dynamic and should be generated from scrath each and every time it is requested. I use filecaching of rarely modified contents at least on three of my websites and I find this practice very useful. What prevents you to drop the cache when the new record is added? You may use server clusters, but sometimes it is possible to think a little and develop some smart algorithm that will do the same on current hardware.

csingsaas, I have to disagree with what you are saying. If server A is pulling a php script from server b, and in that script it MUST pull data from a mysql database on server b, then the querying/processing MUST happen on server B. If that were not the case, the script would give errors, because server A does not have access to the mysql database on server B.

I cannot cache these files, because they are search results that are dynamically displayed. The only solution I can see, is to break up the load on the server, by putting this particular script and database on a seperate server.