PHP load Balancing Guide for large Web application runtime

In the past, running a large Web application meant running a large Web server. Because your application attracts a large number of users, you will have to add more memory and processor to your server. Today, the "big server" model is over, replaced by a large number of small servers, using a variety of load balancing techniques.

The advantages of "more small servers" over the past "large server" model are embodied in two aspects:

1. If the server is down, then the load-balancing system will stop requesting the server to go down and distribute the load to other servers that are running properly.

2. It's easier to expand your server. All you have to do is add the new server to the load balancing system. No need to interrupt your application to run.

So, take this opportunity. The price, of course, is that this requires you to add a bit more complexity to your application development. That's what this article is about to cover.

You might say to yourself, "but how do I know I'm using load balancing?" The honest answer is that if you're asking the question, the answer is that you're mostly not using a load-balancing system and your system doesn't need to consider the problem. In most cases, when the application grows large enough, load balancing needs to be explicitly presented and set up. However, I have occasionally seen virtual hosting companies do this load balancing for customer applications, or do it yourself as described below.

Note that I keep mentioning "web apps" instead of website, which is to differentiate between "web apps" that are complex sites that often involve server-side programming and databases, rather than website that display simple static content.

1. php file

The first question is, if you have a large number of small servers, how do you upload your PHP files to all the servers? Like the following method for your reference:

Upload all the files to each server separately, the problem with this method is: Imagine you have 20 servers, then upload process this will easily lead to errors, and the update is very likely to lead to different versions of the files on the server.

Use ' rsync ' (or similar software). Such a tool can synchronize files on a local directory and multiple remote host directories.

Use version control software (such as subversion). This is my favorite method. It's a good way to maintain my code, and when I publish my application, I can run the SVN Update command sync on every server. This approach also makes it easier to switch the server to a previous version of the Code.

Use a file server (you may find that NFS is a great fit to do this thing). This approach is to use a file server to store your Web applications. Of course, if your file server goes down, then a lot of all your sites will not be available. At this point, you will need to spend more money to restore it.

Choose which way to rely on your needs and skills you have mastered. If you use a version control system, then you may have to plan a method to update the code on all servers if you execute an update command at the same time. However, if you use a file server, you need to implement some failure recovery mechanisms to prevent requests from failing if the server goes down.

2. File Upload

File uploads are not a problem when there is only one server. But when we have more than one server, how should the uploaded files be stored? The problem with uploading files is similar to the Cross server PHP file store. Here are a few possible scenarios:

Store the file in the database. Most data allows you to store binary data. When you request a file download, the Access data outputs the binary data and the corresponding file name and type to the user. You should consider how the database stores your files before using this scenario. The problem with this approach is that if the database server goes down, the file will not be available.

Store uploaded files on a file server. Like the previous introduction, you would install a file server to share with all the Web servers, upload all uploaded files here, and use it for all Web servers after uploading. However, if the file server is down, then an image file download outage may occur.

Design your own upload mechanism to transfer files to the server to every server. This method does not have a single file server or database solution flaw, but will increase the complexity of your code. For example, if you are uploading to multiple servers and the server is down, what do you do with it?

Using a database to store uploaded files but designing a file caching mechanism is a good solution. When the server receives a file download request, it first checks to see if the file is in the cache system and, if so, downloads from the cache system, or reads from the database and caches it to the file system.

3. Session (Sessions)

If you are familiar with PHP session processing, you will probably know by default that it stores session data in temporary files on the server. Also, this file is only on the server you requested to process, but the next request may be processed by another server, which will generate a new session on another server. This causes the session to be frequently unrecognized, as the logged-on user always requires a login again.

My recommended scenario is to either reset the session processing mechanism in PHP to store the session data to the database, or implement your own mechanism to ensure that a user's request is sent to the same server.

4. Configuration (Configuration)

Although this topic is not particularly relevant to PHP, I feel it is necessary to mention it. When running a clustered server, it is a good idea to keep the configuration file synchronization between servers in some way. If the configuration file is inconsistent, it can cause some very strange and intermittent behavior that makes it difficult to troubleshoot these problems.

I recommend using version control systems to manage them separately. This allows you to install different PHP profiles for different projects, or you can keep all the server configuration files synchronized.

5. Log (Logging)

Like configuration issues, logging is not just related to PHP. But it's still very important to keep the server running healthy. Without the right logging system, how do you know if the PHP code starts generating errors (you always turn off the display_errors setting when the system is officially running), don't you?

There are several ways you can achieve logging:

1. Logs are logged on each server. This is the easiest way to do it. Each machine records only one file. The benefits are simple, and may be as small as the configuration. However, as the number of servers increases, it becomes very difficult to monitor log files on each server.

2. Log to a shared method each server still has this log file, but they are stored on a central server through the sharing mechanism, which makes the monitoring log simpler. The problem with this scenario is that if the file server is unavailable, a simple log cannot be written to the problem and eventually the entire application crashes.

3. Log to logging server you can use a logging software, such as syslog, to write all the logs to a central server. Although this method requires more configuration, he also provides the most robust scenario.