PHP's Share-Nothing Architecture (2004) | Hacker News Reader

PHP's Share-Nothing Architecture (2004)

zef.me

14 pointsiand10 comments

This is simply a lie, there are plenty of ways to share data across PHP scripts, but like everything in PHP you have to half ass it. Shared memory extensions immediately come to mind.

PHP wasn't designed around a share-nothing architecture, being able to share data across requests is simply difficult with the random pile of features in PHP.

It's odd that one of the biggest users of PHP (Facebook) decided to remove this and share compiled code across requests. Oddly enough one of the biggest selling points of Zend is that you can share compiled code across requests.

If you can scale a database infinitely (as long as you have enough memory) as the OP suggests then I assure you your webserver will not fall down by sharing a few variables, or even keeping your entire dataset in RAM and shared. Infact if you keep these variables in memory shared across requests you'll scale much further than by putting those variables in MySQL (barring sharding and replication, which generally come with codebase changes anyway).

> but like everything in PHP you have to half ass it. Shared memory extensions immediately come to mind.

No, you do not have to half ass it and using an extension that shares memory is not half assing it, either. You can use APC. You should have it installed already for bytecode caching, but here comes a surprise. Most people don't know that it also has an in-memory key/value store built-in. It works and it works very well. Extremely fast. You also have extensive control over how much and in what way APC uses RAM.

There has been talk of moving APC from PECL and into core for years.

The problem is that if you're using APC on multiple webservers, there's a separate instance of APC running on each server. If you store data in one APC instance, there's no guarantee that the user's following request will hit that same server/instance.

So this works very well for single server systems, but not when scaling to multiple servers, unless there's some process for replication that I'm not aware of?

My team is thinking of using Redis or Memcached to provide a caching layer in front of the web app.

> The problem is that if you're using APC on multiple webservers

Yes. You have two solutions available. Use something like Redis or Memcached, as you noted. The other solution is to go virtual. At that point, you can scale a single instance to a fairly large size.

If a single machine/instance isn't enough to handle your load, you'll end up using something like Redis/Memcached regardless of what platform you're on.

This article contains a number of fallacies. Storing sessions on disk? Over NFS? In the database? Please - no-one does that. And random MySQL bashing? What's that based on? MySQL is used by many high-volume shops to handle huge amounts of data. (See - I don't have to quote examples either!) And magic Oracle scales to infinity? For the kinds of database setups you need with high-performance web apps you can throw the same amount of money at percona.com and get there as well.

[Edit - didn't notice this was a 2004 article]

Disk-based session storage was the default for years and still is. I know of some high-volume sites that used NFS as the sharing mechanism at least up to 2008 and I assume they still do. It kinda works if you do mostly reads. Storing the session in the database was the prime example when session_set_save_handler() was first introduced. The symfony framework still ships with a pdo session handler, so I'd assume people still use it [1] The memcache session handler had major problems with session locking at least as of 2008, I don't know if it's been fixed by now.

[1] https://github.com/symfony/symfony/blob/8ebe624b82dc9f91231e...

Remember this is from 2004, people were doing those things at that time.

Maybe if zef.me was using PHP, it wouldn't be down right now.

Anybody have a cached version?

Google for the URL and look at Google's cache. https://webcache.googleusercontent.com/search?q=cache:GljSc5...

Thanks. I actually tried that and it wasn't in the results.

Reply on news.ycombinator.com