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

ArchitectureUp 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 criteriaPerformances

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 outScale up

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 outThe 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 farmsLots 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 farmsDon'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

ReplicationIdeal 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 writesInitial

Idle

Read

Write

Master Slave1 Slave2

ReplicationLimited 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 strategiesSynchrone 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?

PartitionsSlice 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

PartitionsMake 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 : shardMaster-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

ManagementSQL

Storage

ClusterUseless 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