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

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

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

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

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

Two opposing strategies
Scale up Scale out

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

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,

Web servers farms
Balancer :
Proxy, load

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

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

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

Replication
Writing
Reading

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

Replication : the writes
Initial Master Slave1 Slave2
Idle
Read
Write

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.

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?

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

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

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

Cluster
SQL
Management
Storage

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

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

Elements graphiques