How to make PHP apps scale

The most popular language for Web apps, PHP tends to buckle under heavy loads -- unless you opt for cloud scaling and a NoSQL back end

By Andrew Oliver, InfoWorld |  Software, PHP

Native threads, on the other hand, have a shared memory space as part of their master process. Subprocesses do not have a shared memory space unless you use a specific operating system area called "shared memory." This isn't as fast as being able to pass memory by reference -- besides, the Apache Web Server's "prefork" module doesn't support the use of shared memory for this purpose anyhow. It is sometimes possible to run PHP with native threads, aka worker mode, but this is heavily dependent on the modules you use and whether those modules are "thread safe."

The PHP concurrency model has a major impact on vertical scalability when using a traditional RDBMS. While it's possible to open thousands of unshared concurrent connections to MySQL or Oracle, this has a fairly negative impact on the number of concurrent requests. A typical PHP application -- indeed, any Web application -- consists of logic along these lines:

In this type of code, there are relatively long periods of time where the application is not actually interacting with the database and another request could "share" the same database connection -- if only database connections could be pooled. Since the PHP process model precludes this, you are forced to make a decision: Hold the connection for the duration of the request/response cycle or let go each time the application is done.

The problem with letting go, however, is that it depends on the performance characteristics of opening socket connections. The TCP stack is set up to guard against orphaned packets from a previous connection interrupting a new connection; this is part of the reliability guarantee that TCP draws over IP. The way TCP/IP does this is by making you wait to reuse the same socket connection. Thus, the number of TCP sockets connections you can open in a second is limited. One way of escaping this limit is to reuse connections across multiple request cycles -- a fundamentally sound idea that most PHP applications (due to the PHP concurrency model) simply cannot take advantage of.

If you examine the active connections on your Web server or database server when running a PHP application (on Unix/Linux servers, type netstat -na), you'll see a large number of connections to or from the database in TIME_WAIT or CLOSE_WAIT state. Were you instead running your application on a runtime environment that allowed pooled connections, you would see a fixed number (the size of the database connection pool) in ESTABLISHED state. The bottom line: PHP applications are a load on the database due to the constraints of the concurrency model.

Originally published on InfoWorld |  Click here to read the original story.
Join us:






Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Ask a Question