WebCamp 2016: PHP.Алексей Петров.PHP at Scale: System Architect Toolbox
0 likes213 views
The document outlines the author's expertise as a system architect and PHP developer, detailing performance metrics of a demo application using various tools and services. It emphasizes the strategies for scaling applications, such as using load balancers, caching mechanisms, and differentiating between horizontal and vertical scaling. The author provides insights on database performance, particularly focusing on the challenges of scalability and the importance of proper system architecture.
![[phantom]
address=555.166.5.74 ; fake ip
port=80 ;target port
rps_schedule=step(20, 60, 10, 30s) const(1, 30s) ;load scheme
uris = /ru/blog/
Yandex Tank Config](https://image.slidesharecdn.com/php-at-scale-system-architect-toolbox1-160817164422/85/WebCamp-2016-PHP-PHP-at-Scale-System-Architect-Toolbox-5-320.jpg)
WebCamp 2016: PHP.Алексей Петров.PHP at Scale: System Architect Toolbox
- 2. Who am I System Architect Team Lead PHP Developer Find me on @alexhelkar alexhelkar https://github.com/alexhelkar
- 4. Canvas PHP 7.0.8 Digital Ocean 5$ Droplet Symfony 3 Demo Application Yandex Tank
- 5. [phantom] address=555.166.5.74 ; fake ip port=80 ;target port rps_schedule=step(20, 60, 10, 30s) const(1, 30s) ;load scheme uris = /ru/blog/ Yandex Tank Config
- 6. Results
- 7. Results Max. stable RPS: 50 Response time: ~20ms
- 8. PHP 7 facts isset 1.55 times faster than array_key_exists is_file 26 times faster than file_exists single quotes slower that double quotes instanceof faster is_a etc. Code performance?
- 9. Blackfire.io profile Current results: Total request time: 18.4 ms file_exists called: 7 times Exec. time for file_exists: 460 µs Expected results: Exec/ time: ~17.6 µs Total request time: ~18.3996 ms
- 10. Perfomance Response time? Requests per second?
- 12. SLA Story
- 13. Demo App recall with $$ Infrastructures scaling
- 14. 5$ RAM: 512 CPU: 1 HDD: 20 50 RPS App Server
- 15. 10$ 50 RPS App Server RAM: 1024 CPU: 1 HDD: 30 50 RPS App Server RAM: 512 CPU: 1 HDD: 20 LB Server RAM: 512 CPU: 1 HDD: 20
- 16. 15$ 100 RPS App Server 50 RPS App Server LB Server 5$ App Server RAM: 512 CPU: 1 HDD: 20 RAM: 512 CPU: 1 HDD: 20 RAM: 512 CPU: 1 HDD: 20 RAM: 1024 CPU: 1 HDD: 30
- 17. 20$ 160 RPS App Server 120 RPS App Server LB Server App Server App Server RAM: 2048 CPU: 2 HDD: 40 RAM: 512 CPU: 1 HDD: 20 RAM: 512 CPU: 1 HDD: 20 RAM: 512 CPU: 1 HDD: 20 RAM: 512 CPU: 1 HDD: 20
- 18. Summary Often hardware is cheaper than software Often scaling is cheaper than tuning Often horizontal scaling wins vertical scaling Often applications are not scalable :(
- 22. Good to know HAProxy TCP and HTTP Load Balancing Nginx HTTP Load Balancing Message Queue-Based Load Balancing
- 24. MQ Balancing
- 25. Consumer retries
- 26. API Gateway
- 27. Benefits we've got Advanced routing of requests Advanced routing of responses Workers could be added dynamically without LB reconfig Buffer size by queue limit Back pressure by message TTL
- 29. Generic Web App
- 33. DNS Cache
- 34. Rule of Thumb: Add LB
- 35. What if?
- 36. Floating IP
- 38. Reads Flow
- 39. DB Cache
- 41. Application Cache Candidates Memcached (sessions, k/v data) sessions k/v data Redis k/v data leaderboards durability replication * Manual sharding both cases
- 42. Web Cache
- 43. Cache: Rule of thumb IF Application is SLOW Enable Caching IF Application has GLITCHES Disable Caching
- 45. Cirquit Breaker
- 46. Fire & Forget
- 48. MySQL Story of 100 servers
- 49. MongoDB Chose correct sharding key
- 52. Apache Kafka 2 billions messages on 3 machines
- 53. Distributed Locks Consul || etcd || Zookeeper
- 54. Instead Summary Scalability as afterwords doesn't work Database is not a queue Database is not a lock system Redis is not a queue MySQL master is always SPOF Load balancers as a must Linear disk writes wins Perfomance in PHP is done by everything except PHP Being distributed is fucking hard