Web applications requires robust PHP and MySQL architectures. This may be for high availability, for sheer performances, or even both. Yet, there is always the nagging question of doing so in an economically viable way. Architecture is not black magic : coming right from the mission goal, it will take most of the load and still look nice in the accounting tables. During this session, we'll study a number of architectures solutions available to modern PHP architects, and discuss about their impact on availability, performances, PHP programmation, MySQL organization and econometrics.

1. PHP/MySQL
Architectures
November 7th, 2007,
Washington DC, USA

2. Who is speaking?
Damien Seguy
Expert services for Nexen Services
Statistics provider (and ISP killer)
Phather of thousands of elePHPants
damien.seguy@nexen.net

3. Architecture
Up to two servers is quite obvious
Organize PHP/MySQL application to go beyond 2 servers
How one can add more servers then?
Keep going up in scale and size

4. What is your problem?
Too much to process?
Too much traffic?
Too much data?
Too much reads?
Too much writes?

5. Architecture criteria
Performances
Fast to answer
High availability (HA)
Always accessible, even slowly
Evolutivity
Going up, going down
Marginal cost of adding one server

6. Two opposing strategies
Scale up Scale out

7. Scale up
'Mine is bigger' Syndrom
Really expensive
To buy
To keep up
Less impact on PHP code
Actually solve problems
Temporarily
No way to go back, or just a little

8. Scale out
The Farming syndrom
Cheap to reasonnable
Easier to evolve one piece a time
Significant impact on PHP code
The virtualization buzz
Automate your installations
puppet, Phing, Pear channels,

9. Web servers farms
Balancer :
Proxy, load

10. Web servers farms
Lots of work for PHP
Dispatching, personnalization,
tracking
Solutions
Export static to a CDN
Akamaï, Amazon S3, Youtube,
Caches, caches, caches
HTML, data, SQL, PHP,
Use the 'Share nothing' strategy

11. Web servers farms
Don't tie yourselves to servers
When you need to share : sessions
Session via NFS
Session in a filer
Session in the database
Zend platform
Sessions in memcache

12. Database problems
Read Writing Catch
Replication Yes No Lag
Partitions No Yes Application
Cluster Yes Yes Management

13. Replication
Writing
Reading

14. Replication
Ideal for backup or reports
Works great to spread the load
geographically
Excellent for web applications
Lots of read, less writes
Easy to set up and on budget

15. Replication : the writes
Initial Master Slave1 Slave2
Idle
Read
Write

16. Replication
Limited by writing
Master is idle
Slaves are overworked
Master is SPOF
Master fails, world crumble
Persistant problem of lag
Will slaves ever catch up?
The chore of resynching.

17. Replication strategies
Synchrone replication from Google
Ensure queries are also on the
slaves
Send writing to master, reading to
slaves
Share tables on different servers
Avoid round trip for fast info
What kind of lag can you accept?

18. Partitions
Slice your data on several servers
MySQL 5.1 has partitions
Start early by splitting your tables
Then put those tables on two
servers.
Allow extra storage capacity
Raise the writing performances
Reduce size of each tables
Easy on budget

19. Partitions
Make every group command a chore
No GROUP BY, no UNIQUE
The key is the partition strategy
Bills : by dates
Users : by accounts, by group?
Need yellow pages to know where
is what
Huge impact on the PHP application
Need for consistent admin scripts

20. Partitions + replication : shard
Master-master replication
Writing goes to both servers
Easy to set up and configure
High availability
No waste of ressources
Handles reads and insert
BUT subtle delete and update

21. Cluster
SQL
Management
Storage

22. Cluster
Useless below four machines
Individual performances start lower
Then, they don't change much
NDB is not InnoDB nor MyISAM
Still difficult to configure
This is the way to go

23. Questions?
http://www.nexen.net/
conferences.php
damien.seguy@nexen.net

24. Elements graphiques