7. Nuvola
● > 3M HTTP requests / day
● ~ 1000 databases
● ~ 350GB mysql data
● ~ 180M query / day
● ~ 25M of media files
● ~ 4.50TB of medis files
● From ~5k to ~200k sessions in 5 minutes
8. Scalability
Your app is scalable if it can adapt to
support an increasing amount of data
or a growing number of users.
9. “But… I don’t have an increasing load”
(http://www.freepik.com/free-photos-vectors/smile - Smile vector designed by Freepik)
10. “Scalability doesn’t matter to you.”
(http://www.freepik.com/free-photos-vectors/smile - Smile vector designed by Freepik)
11.
12. “I do have an increasing load”
(http://www.freepik.com/free-photos-vectors/smile - Smile vector designed by Freepik)
38. PHP code / Profiling
XHProf
Blackfire
New Relic
39.
40.
41. PHP code / Recap
● Easy
● No need to change your PHP code
● It’s most configuration and tuning
● You can do one by one and measure how it affects performance
● Need to monitor and profile: New Relic for PHP
● Don’t waste time on micro-optimization
Take away: use cache!
42. Sessions
● Think session management as a service
● Use centralized Memcached or Redis (Ec2
or ElasticCache on AWS)
● Avoid sticky sessions (load balancer set up)
43. Session / Memcached
No bundle required
https://labs.madisoft.it/scaling-symfony-sessions-with-memcached/
48. Session / Recap
● Very easy
● No need to change your PHP code
● Redis better than Memcached: it has persistence and many other features
● Let AWS scale for you and deal with failover and sysadmin stuff
Take away: use Redis
56. Database / Big db problems
● Very slow backup. High lock time
● If mysql crashes, restart takes time
● It takes time to download and restore in dev
● You need expensive hardware (mostly RAM)
57. Database / Short-term solutions
Use a managed db service like AWS RDS
● It scales for you
● It handles failover and backup for you
But:
● It’s expensive for big db
● Problems are only mitigated but they are still there
60. Database / Sharding
● Very fast backuo. Low lock time
● If mysql crashes, restart takes little time
● Fast to download and restore in dev
● No need of expensive hardware
● You arrange your dbs on many machines
61. Database / Sharding
● How can Symfony deal with them?
● How to execute a cli command on one of them?
● How to apply a migration (ie: add column) to 1000 dbs?
● …...
63. Database / Sharding
Define a DBAL connection and a ORM
entity manager for each db
https://symfony.com/doc/current/doctrine/multiple_entity_managers.html
67. Database / Doctrine sharding
● Suited for multi-tenant applications
● Global database to store shared data (ie: user data)
● Need to use uuid
http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/sharding.html
69. Database / Sharding
ShardManager Interface
$shardManager = new PoolingShardManager();
$currentCustomerId = 3;
$shardManager->selectShard($currentCustomerId);
// all queries after this call hit the shard where customer
// with id 3 is on
$shardManager->selectGlobal();
// the global db is selected
70. Database / Sharding
● It works but it’s complex to be managed
● No documentation everywhere
● Need to manage shard configuration: adding a new
shard?
● Need to parallelize shard migrations: Gearman?
● Deal with sharding in test environment
71. Database / Recap
● NOSQL is not used to scale SQL: they have different purposes. You can
use both.
● Sharding is difficult to implement
● Need to change your code
● Short-term solution is to use AWS to leverage some maintenance
● Doctrine ORM sharding works well but you need to write code and
wrappers. Best suited for multi-tenant apps
● When it’s done, you can scale without any limit
Take away: do sharding if your REALLY need it
79. Filesystem / Recap
● Easy
● Need to change your PHP code
● Ready-made bundles
● Avoid local filesystem and NAS
Take away: use FlystemBundle with S3
80. Scaling / Recap
● Sessions and filesystem: easy. Do it
● PHP code: not difficult. Think of it. Save money.
● Database: very hard. Think a lot
● Queue systems, http cache and some other stuff: next
talk but think of them as services
