| 1 | # Photon Principles␊ |
| 2 | ␊ |
| 3 | The core priorities of the Photon project are:␊ |
| 4 | ␊ |
| 5 | - Speed.␊ |
| 6 | - Ease of development.␊ |
| 7 | ␊ |
| 8 | Starting version 1.0 speed regressions will not be allowed. That is,␊ |
| 9 | each new version of Photon will have to be at least as fast as the␊ |
| 10 | previous if not better for a set of standardized tests.␊ |
| 11 | ␊ |
| 12 | # Technology␊ |
| 13 | ␊ |
| 14 | Daemon. Yes, a daemon in PHP. This works perfectly well as it is used␊ |
| 15 | in combination with Mongrel2. Mongrel2 allows us to start/stop daemons␊ |
| 16 | in PHP extremely easily without disruption of the requests. For␊ |
| 17 | example, you can set your daemon to shut itself down after 500␊ |
| 18 | requests or after reaching a certain level of memory consumption. You␊ |
| 19 | let the mongrel2 process supervisor restart the process (it is PHP so␊ |
| 20 | it is extremely fast) and you just enjoy automatic cleaning of the␊ |
| 21 | memory leaks while getting an extremely robust system.␊ |
| 22 | ␊ |
| 23 | Depending on your system (that is, if you have many cores) you can run␊ |
| 24 | many backend PHP processes to fully use your cores and get the maximum␊ |
| 25 | out of your system. You can also have a smart way to start/stop PHP␊ |
| 26 | backend processes depending on the load (you can even start them on␊ |
| 27 | other systems).␊ |
| 28 | ␊ |
| 29 | # Methodology␊ |
| 30 | ␊ |
| 31 | In memory. The goal is to hit the disk only when really needed. So all␊ |
| 32 | the tradeoffs are towards putting more in memory and have less disks␊ |
| 33 | access and system calls.␊ |
| 34 | ␊ |
| 35 | Cryptography to allow stateless communication (signed cookies) and␊ |
| 36 | permit authentication without the need to hit the database or even␊ |
| 37 | open a connection to the database.␊ |
| 38 | ␊ |
| 39 | Smart "core" objects which are database independent even so most of␊ |
| 40 | the code is structured to take benefit of MongoDB.␊ |
| 41 | ␊ |
| 42 | MongoDB, because it is fast and nicely answers our needs:␊ |
| 43 | ␊ |
| 44 | - Fast development of new models.␊ |
| 45 | - No real needs of migrations, they can be handled at the code level on a running system.␊ |
| 46 | - Memory mapped, that is, no disk access when the dataset is small.␊ |
| 47 | ␊ |
| 48 | Use PHP. This may be a surprising remark, but most of the frameworks␊ |
| 49 | tend to reinvent the PHP builtin functions and classes, just don't do␊ |
| 50 | it. Use PHP as much as possible, this is faster and safer on the long␊ |
| 51 | run.␊ |
| 52 | ␊ |
| 53 | # Critics␊ |
| 54 | ␊ |
| 55 | It Sucks, I Cannot Use It On Shared Hosting. Yes, but the goal here is␊ |
| 56 | to provide a high performance PHP framework for websites with␊ |
| 57 | performance constraints. If you are on a shared hosting, you would be␊ |
| 58 | better served with a already very fast framework like Pluf.␊ |
| 59 | ␊ |
| 60 | A daemon in PHP, PHP is a memory sieve, so we can forget about␊ |
| 61 | it. Already the fast-cgi approach has a per children request limit␊ |
| 62 | (500 by default) to kill and restart a children after a while to plug␊ |
| 63 | the memory leaks. So, this is the same approach.␊ |
| 64 | ␊ |
| 65 | ømq is another piece of infrastructure we do not need. Yes and no, the␊ |
| 66 | wonder of ømq is that we can even use it to dispatch the requests to␊ |
| 67 | other processes (Python, Ruby, Java) to offload some of the work to␊ |
| 68 | specialized systems.␊ |
| 69 | |
