Creating a Web application (actually writing the core code) is usually the initial focus of the project. It's fun, exciting, and it's what you are driven to accomplish in your project. However, people always hope that their applications can handle higher traffic than initially expected. In this case, people often start to think about how to expand their website.
Ideally, you should think about how to extend your application when you first write code. This is not to say that you should invest a lot of energy in the early development process facing the unknown future. Who knows what will happen in the future? Who knows if your application needs scalability work to reach traffic levels? But we hope that you can learn the most important lesson from here, which is to understand what work needs to be expanded in the future. After understanding this, you can do only the work you need at all stages of the project, and avoid "getting yourself into a coding dilemma", which makes it difficult to carry out the next step of scalability.
I have worked for many companies and have participated in many projects, all of which need to deal with massive web traffic over time. These include the Digg, TripAdvisor and Hubble Space Telescope projects. In this article (divided into two parts), I will share with you some of the experiences and lessons I have learned, and guide you step by step through the standard process of extending the application.
Performance and scalability
Before going further, we should discuss the similarities and differences between performance and scalability.
In a Web application, performance refers to the speed at which data (pages) are provided to the end user. When people talk about improving application performance, they are usually talking about reducing the time to generate content from 500 milliseconds to 300 milliseconds.
On the contrary, scalability refers to the ability to support applications that increase as traffic grows. In theory, no matter how high the traffic is sent to it, a scalable application can handle that traffic by increasing its capacity.
Scalability and performance are obviously interrelated. When improving application performance, the fewer resources to expand, the easier the expansion. Similarly, if an application needs to have a
Web server for each user in order to provide high enough performance, it cannot be said to be scalable because you cannot provide so many servers.
PHP tuning
You should first understand all the easiest goals in the web server and PHP setup. You can see that some very simple operations can immediately improve performance, and may reduce current expansion requirements, or at least simplify expansion.
The first simple operation is to install the opcode cache. PHP is a scripting language, so the code is recompiled on every request. Installing opcode caching in your web server can circumvent this restriction. It can be considered that the opcode cache is located between PHP and
the server computer; after the PHP script is compiled for the first time, the opcode cache will remember the compiled version, and subsequent requests will only extract the compiled version.
There are many types of opcode caches that can be used. Zend
Server comes with a built-in opcode cache, and Microsoft also provides an opcode cache for Windows computers called "WinCache". One of the most popular opcode caches is the open source product APC. The installation of any of these products is very simple, and doing so can immediately bring you significant performance improvements.
In the next step, you need to evaluate whether you can remove the dynamic nature of any Web page. Web applications often have some PHP-generated pages, but they actually rarely change. For example, a "FAQ" page or press release. Cache these generated pages and provide the cached content so that PHP does not need to perform any tasks, thus saving a lot of CPU cycles.
There are several ways to accomplish this task. One way is to generate HTML pages in advance through PHP and provide the HTML pages directly to the end user. This may be done at night, so that any update to the Web page can actually achieve real-time results, but there is a delay in planning. Achieving this task is very simple, just run the PHP script from the command line, pass the output to the .html file, and then change the link in the application.
However, there is another way to accomplish this task more easily: to implement dynamic caching. Basically, the output of the entire script will be captured in entities such as file system buffers, memory/cache, or databases. All future requests for the script only need to read the cached copy. Some templating systems (such as Smarty) will do this automatically, and some good informal packages can also do this for you (such as jpcache).
You can easily write the simplest version of code to accomplish this task: the following code injected into the top of a typical PHP page will do this for you (obviously you need to replace the timeout and cache directories to meet your needs). Encapsulate it as a library function, and you can easily cache pages as needed. In this way, it simply caches the page based on the URL and GET parameters. If the page changes are based on sessions, POST data or cookies, they need to be added as unique content of the created file.
<?php
$timeout = 3600; // One Hour
$file ='/tmp/cache/'. md5($_SERVER['REQUEST_URI']);
if (file_exists($file) && (filemtime($file) + $timeout)> time()) {
// Output the existing file to the user
readfile($file);
exit();
} else {
// Setup saving and let the page execute:
ob_start();
register_shutdown_function(function () use ($file) {
$content = ob_get_flush();
file_put_contents($file, $content);
});
}
?>
Load balancing
When creating a web application, everyone starts with a server that can handle everything. This is perfect, and it is the usual way. When extending a Web application to handle more traffic, the first step that needs to be completed is to equip multiple Web servers to handle requests. PHP is particularly suitable for horizontal expansion in this way, just add more
web servers as needed. This will be handled through load balancing. Fundamentally speaking, load balancing is just a concept with a central point. All requests are transmitted to the central point, and then these requests are distributed to various Web servers.
There are many options for operational load balancing. Most of them can be divided into three different categories.
The first is a software balancer. It is software that can be installed on a standard computer (usually based on Linux) and will handle all load balancing for you. Each software balancer also comes with its own additional features, such as built-in page output cache, gzip compression, etc. In fact, most of the popular options in this category are multi-purpose software/Web servers with reverse proxy mode. You can enable reverse proxy mode to achieve load balancing. This includes Apache itself, Nginx and Squid. There are also some smaller dedicated load balancing software, such as Perlbal. You can even implement a very simple load balancing in the DNS server, which uses DNS round robin to make each DNS request respond with a different IP address, but its flexibility is obviously lacking.
The second is the hardware balancer. This is a physical machine that can be purchased, designed to handle very high traffic and has custom software built in. The two more well-known versions are Citrix Netscaler and F5 BigIP. Hardware solutions often provide many customized advantages and can also act as firewalls and security barriers.
The last one is a new cloud-based solution. Because it is hosted by a cloud provider, you obviously cannot install hardware-based solutions, so you can only use software solutions. However, most cloud providers have their own built-in mechanisms for load balancing across instances. In some cases, these mechanisms are not flexible enough, but they are easier to set up and maintain.
Finally, all solutions (whether software or hardware) usually provide many of the same features. Can manipulate or cache incoming data, can achieve load balancing by random selection or by viewing the health table on each slave computer, and so on. I recommend that you learn about the options that are suitable for the hosting environment and find the most suitable option. You can get a setup guide for any solution from the Internet, which covers all the basics.
Load balancing preparation
As mentioned earlier in this article, it is very important to complete only the required tasks, but at the same time you must be psychologically prepared for the next step. When building an application for the first time, you will rarely establish load balancing, but you should remember to make sure to complete this step later.
First, if you use any type of local memory caching solution (such as the one provided by APC), then you need to write code and don't assume that there is only one cache. With multiple servers, the data stored on one computer can only be accessed through that computer.
Similarly, a single file system has the same drawbacks. After using multiple servers, PHP sessions can no longer be stored on the file system, so you need to find another solution (such as a database) for them. I have also seen code that stores uploaded files and hopes to read them back later. Therefore, you need to assume that nothing should be stored on the file system.
Now, if you find it necessary to develop the initial application quickly, you can still use the methods listed earlier. The important thing is to encapsulate any "single computer" related code. Make sure it is in a single function, or at least in a class. Then, when you start to implement load balancing, you only need to update one part of the new solution.
MySQL master-slave replication
Now you have given the Web server good scalability. Most Web applications have discovered their next bottleneck: the database itself. MySQL is very powerful, but you will end up with the same problem as a web server, that is, only one database is not enough. To this end, MySQL comes with a built-in solution called master-slave replication.
In the master-slave setting, you will be equipped with a server as the master server, that is, the true database of data. Then, you will set up another MySQL server and configure it as a slave to the master server. All operations that occur on the master server will be replayed on the slave server.
After completing the configuration in this way, you will ensure that the code communicates with the "correct" database, depending on the actions that need to be taken. Whenever you need to change the data on
the server (change, delete and insert commands), you will connect to the main server. For read access, you will connect to the slave server. This is very simple, as shown below:
<?php
$master = new PDO('mysql:dbname=mydb;host=127.0.0.2', $user, $pass);
$master->exec('update users set posts += 1');
$slave = new PDO('mysql:dbname=mydb;host=127.0.0.3', $user, $pass);
$results = $slave->query('select id from posts where user_id = 42');
?>
Using this method to achieve scalability has two benefits. First, you managed to split the database load into two parts. Therefore, the load of each server is immediately reduced. This is usually not an even division; most web applications have very high read loads, so the slave server will take on more load. But this leads to the second point: isolation. Now you have isolated two different types of loads, namely write and read. This will give you more flexibility to take the next scalability steps.
You can refer to Extend the PHP MySQL Web Application Series 2 and get the following content.
