It is more convenient to extend PHP with the cloud

As the most popular Web application language of our time, PHP is too cumbersome, unless you choose Cloud Extension or NoSQL Background, otherwise it will be a very troublesome process.

The power of PHP versus traditional relational databases is that they allow junior developers to quickly find the key features of some applications. Unfortunately, the default runtime environment used by PHP is not only confusing but also difficult to scale.

There may be a lot of people do not care about the maintainability of PHP. Their PHP application is discarded, its load is quite heavy, and often run in parallel. For example, there was a company that had developed an application that uses Oracle back office as a PHP marketing application. Customers can use this application to buy goods, and use "points" in exchange for some of the features of an online game. The app has been operating well, but the situation has changed when the number of users reaches millions.

The fact is that if you have enough servers and plenty of database servers, then there's no problem. However, due to the fact that PHP's Web application is at the top level, relational databases can not be extended with excellent cost-effectiveness (input-output ratio) to provide excellent read-write performance. Practice has proved that the solution to this problem is: Cloud and NoSQL integrated use. The cloud infrastructure allows us to have ample servers and the NoSQL database allows us to share data more efficiently. But here, let's take a look at the root cause of the confusion in the PHP environment.

PHP operating environment how bad?

The most common PHP runtime is the Apache Web Server pre-descendent (Prefork), where a web server runs a series of separate child processes to support parallel requests. When you combine this parallelism with traditional relational databases such as MySQL, PostgreSQL, or Oracle, such choices mean non-pooled database connections because the database connection pool requires a shared memory space.

On the other hand, native multithreading has a shared memory space as part of its main process. Subprocess does not have a shared memory space, unless you use an operating system called "shared memory." Its speed can not be compared with passing memory according to the index. In addition, Apache Web Server's "pre-derived" module does not support the use of shared memory. In many cases, PHP is likely to work with native multithreading, ie employee mode. However, it depends heavily on the modules you use and whether these modules have "thread-safe" features.

When using a relational database, PHP parallel mode will have a significant impact on vertical scaling mode production. Although it can open thousands of non-shared parallel connections to connect to MySQL or Oracle databases, it has a negative impact on a large number of parallel requests. A typical PHP application (in fact, any Web application), is composed of the following logic:

request -> getData -> doStuff -> getMoreData -> doMoreStuff -> WriteData -> sendReponse

In such code, there is a relatively long period of time during which the application is virtually unable to interact with the database. Another request can "share" the same database connection, provided that the database connection can be aggregated. Since this mode has been disabled in PHP processing mode, you can only be forced to make the decision whether to keep the connection for the continuation of the request / response loop or to run each time the application is executed.

But the problem is that it depends on the performance characteristics of the open socket connection. The TCP stack is used to prevent orphaned packets previously produced by the connection from interfering with the new connection. This is part of ensuring that TCP covers IP. The working mechanism of TCP / IP is to allow users to wait for the same socket connection to be reused. Therefore, the number of TCP socket connections you can open within one second is limited. The way to get out of this restriction is to reuse the connection in a multi-request loop. However, PHP parallelism has led most PHP applications to exploit this approach.

When running a PHP application (on a Unix / Linux server with netstat -na type), if you check for active connections on the web server or database server, you will see a large number of connections with TIME_WAIT or CLOSE_WAIT between databases. If you instead run the application on a runtime environment that allows pooled connections, you can see the number of ESTABLISHED states (based on the size of the database connection pool). The essence is that due to the restrictions of parallel mode, PHP application is a load on the database.

What is the reason? Linux did not initially support multi-threaded, only support sub-process. Windows NT operating systems have always supported multithreading, albeit much clunky compared to modern native Linux multithreading. Therefore, it has a big advantage over Linux. But unfortunately, no one believes these Microsoft-sponsored research results.

In order to extend PHP in a relational database, you need to slice your data. This means that the data should be disassembled in a reasonable manner. This may mean that customers in different geographies need to access different relational databases. It was precisely because of the so-called "simple" and "free", you will choose PHP. But when you choose PHP, you will have to face a lot of intricacies.

Cloud and NoSQL: game rules disruptor

In cloud computing mode, PHP can scale perfectly if you're able to swap out a database with autoshard that balances each node's connection. Instead of creating a series of non-pooled connections to one or two machines, you can balance across multiple database servers.

More and more web servers limit the impact of lack of connection pooling on database clients. More database nodes and partitions reduce the impact of server nodes. The trend has been very clear, turning NoSQL and the cloud can be expanded on the existing operating environment. PHP's success is due to its economics, a feature that may push it to be more successful on the cloud instead of revising PHP thread safety as it has done before.

Overall, the benefits of a combination of cloud and NoSQL eased these contradictions or made the application easier to deploy. This means that with a sound NoSQL solution and a sound cloud deployment plan, we might be able to hire an offshore PHP programmer team to turn to a NoSQL database.