Women in Technology

Hear us Roar

Article:		The PHP Scalability Myth
Subject:		Fundamental Platform Differences and why PHP scales better
Date:		2003-10-16 12:52:53
From:		anonymous2
Response to: Fundamental Platform Differences and why PHP scales better
It's both a performance and scalability issue but perhaps wasn't specific enough simply to say "no databases". Regarding scalability, essentially you don't want to store high demand but disposable user session state data (which in a desktop app, for example, you'd keep in memory) in the _same_ database as the real application data, otherwise you can't scale the layers seperately. Regarding performance, it's a good idea to keep session data as "close" to the script that needs. You might use a seperate, _local_ database (PHP5 has SQLite built in which, interestingly, is capable of storing data in memory as well as a file) but, arguably, you want the path to session store to be as clear as possible (certainly if it needs a network call, that's bad news). Also from an maintence point of view, the less complexity you add, the better your chances when things go wrong and the lower your operating costs. As you scale, you can turn to stuff like IBM's Parallel Linux File System for handling session data.

Showing messages 1 through 6 of 6.

Fundamental Platform Differences and why PHP scales better
2003-10-16 12:58:36 anonymous2 [View]

MySQL is actually quite a bit faster than SQLite for simple single-key selects like this. It makes a good session database. Memcached (http://www.danga.com/memcached/) is good for this too.

Fundamental Platform Differences and why PHP scales better
2003-10-16 20:21:09 anonymous2 [View]

MySQL HEAP tables could be an option too I think, the ones that stay in memory.

Fundamental Platform Differences and why PHP scales better
2003-10-17 10:23:50 anonymous2 [View]

That's what I use (with a custom sessions handler), and it works great.

Fundamental Platform Differences and why PHP scales better
2003-10-17 13:38:11 anonymous2 [View]

In an ideal world, yes, it would be fantastic to always have an up-to-date session store right in the same machine as the code that's trying to access it. Unfortunately, in any kind of horizontally scaled solution, it's not always possible. If you are dealing with a large group of users, there will come a point where your HTTP front end (whether it be a servlet or PHP script) WILL have to consist of more than one machine. That means, you'll have to either synchronize sessions between the application servers or store the session data in a central repository that all app servers have access to (through either a roll-your-own solution using PHP database calls or though RMI communication to an EJB layer that's handling persistent session data). Either way, the network call is a necessary burden to get your application to scale in any kind of meaningful way.

Fundamental Platform Differences and why PHP scales better
2003-10-17 13:41:13 anonymous2 [View]

In an ideal world, yes, it would be fantastic to always have an up-to-date session store right in the same machine as the code that's trying to access it. Unfortunately, in any kind of horizontally scaled solution, it's not always possible. If you are dealing with a large group of users, there will come a point where your HTTP front end (whether it be a servlet or PHP script) WILL have to consist of more than one machine. That means, you'll have to either synchronize sessions between the application servers or store the session data in a central repository that all app servers have access to (through either a roll-your-own solution using PHP database calls or though RMI communication to an EJB layer that's handling persistent session data). Either way, the network call is a necessary burden to get your application to scale in any kind of meaningful way.