DutchPIPE Issues

Introduction

There are some problems I encountered, mainly PHP 5 related. In summary, PHP 5 tries to be an object oriented language, sort of, but it isn't of course.

This is not a complete list.

Problem 1: One Big Name Space

The DutchPIPE server/universe creates one big name space. This for instance means each object must have a unique class name, which is a problem when you have a lot of pages. Because these classes are final the solution might be to let the system generate unique class names, remove class definitions from objects in the universe, and make it trully file based, which it is already anyway. So:

test.php

1. inherit(DPUNIVERSE_STD_PATH . 'DpObject.php');
2.  
3. class Test extends DpObject()
4. {
5.     foobar();
6. }

would simply become:

1. newinherit('DpObject.php');
2.  
3. foobar();

and the system would generate something like 'class Generated35342 extends DpObject' for internal use.

Problem 2: Fatal Errors

A fatal error in an object anywhere, will crash the whole site, not just that page or object for that user. Remember, we're running one big script where all created users, pages and other objects reside.

PHP throws a lot of fatal errors, and there is no escape. For instance, if you add a new page and have code in it which calls a non existing method (you typed $this->getTitel instead of getTitle), the entire site crashes when that code is executed.

PHP 6 might do better, but that's of no help now. Essentially, it is very, VERY bad if person A encounters a PHP scripting error on the FAQ page and it resets the whole site for everyone, including people with shopping carts elsewhere on the site.

Of course, what I'd like PHP to do is if an object produces a fatal error, well, that object produces a fatal error, it might even get destroyed, but the entire script doesn't. The script should just be notified that object has an error.

Having said all this, DutchPIPE.org in reality is quite stable, running for days without problems.

There are some tools planned to lower your chances of this happening:

• Syntax checkers: PHP from the command line can check a PHP file for syntax errors. Likewise, I've been experimenting with the PHP runkit module, which can do something similar. This might become a future option, but not for now (runkit is still experimental).

  Syntax checking won't protect you from ill-named methods and such though.

• True persistence by use of a database: It is something which needs to be explored and will be inevitable anyway. For instance, you want to restart the server without users noticing it. Currently, objects are only stored in memory and this should be improved with more options. Storing objects in a database has of course performance penalties.

• True persistence by use of an "alternate universe": Well this would be just wicked... one DpUniverse would be what you see and what you operate on, the other is an exact copy, but only contains and gets updates of the state of the first. When the first one is destroyed with a spectacular event horizon, for whatever reason, dpserver.php could just scratch his head, switch to the second as if nothing happened, and start making another shadow. This would have a lesser performance penalty but uses more memory. Which reminds me...

Problem 3: Memory Management

Dynamic object oriented worlds, memory and PHP don't combine well yet. It doesn't use much memory, but the problem is it doesn't free it either when I want to.

For example, if I have 1000 pages, the server would slowly fill with object instances as people wander around the site. When all pages are visited, dpserver will contain 1000 page objects. What I'd like is if I've 1000 pages, it should only keep, say, the 100 most popular or last visited in memory, and destroy page objects with no one in them. They can be recreated when someone enters that page again. Just a normal cleanup mechanism.

Now I can destroy the instances of object classes with PHP (unset) so I would have just 100 objects, but I -can't- destroy the original class from which it was constructed. If all pages are unique, there are still 1000 classes in memory.

This also means you can't reload classes. If you change mybeer.php, you must restart the server to see the result. In a better object oriented world, I would be able to reload it within the existing universe (autoclassing can solve this too).

Possible future solutions include using PHP functions to construct and aggregrate objects and methods on the fly. (This would also allow for multiple inheritance, another omission). Currently these functions are still experimental and I need them to be standard. What it would allow is an abstraction layer over the 'new' construct, which uses a pool of a limited numer of 'empty' objects to construct new ones.

For DutchPIPE.org, a small site, I set the memory limit of the PHP script in php.ini to 16MB. It didn't run out of memory yet, consuming just over 1MB when the site is fairly crowded. But it doesn't have hundreds of pages with forum talk, bug tracking, documentation, etc. yet. A quick solution might be to see if your site balances out to some reasonable memory usage over the period ofsay, one day, and then restart the server at the quietest moment, say 3AM of the time of your target adience. Of course they will be everywhere around the globe, but most sites do have most of their target adience near.