Performance profiling and testing of symfony application 2
0 likes1,619 views
This document discusses performance profiling and testing of a Symfony application. It recommends using tools like the Symfony profiler toolbar, Blackfire, and logging to measure metrics like SQL query times, external API calls, memory usage, and more. Capturing these metrics during testing and in production helps identify bottlenecks in the code related to performance. The goal is to measure code quality from a performance perspective and ensure the application meets requirements for speed and responsiveness.
Performance profiling and testing of symfony application 2
- 1. Performance profiling and testing of a Symfony application
- 3. About me ● Developer Advocate ● Release Manager ● Trainer ● Team Leader ● Software Engineer at
- 4. Performance profiling Finding bottlenecks in the code to make it work faster
- 5. Performance testing - The process of evaluating the quality or capacity of a product. - Performance testing is vital in the software development lifecycle.
- 6. The goal To measure code quality
- 7. Profiling without testing - Possible only when your project will not be changed. - If the code is left tested, even one line can break everything with the damage discovered by clients already in production.
- 8. When do we need profiling? - The website is down because of overload - Website load takes more than 2 seconds (performance is a mandatory feature of any website) - How One Second Could Cost Amazon $1.6 Billion In Sales
- 9. When we don’t need profiling? - The customer said there would have a significant load in production without giving any proof. - Premature optimization is almost always a bad idea. This doesn’t mean you should use $repo->findAll()->paginate(), This means: don’t do profiling when there are no performance issues.
- 10. Step #1 At ORO we started with: - A time limit for Behat tests - A network tab in the Chrome Dev Toolbar
- 11. Issue #1 Time is a good but unreliable metric. How to know when time goes up because of: - VM load - CPU throttling - Network issues - Unreliable external API - Or bad code ?
- 12. If the website has slowed down, you can blame: - A software developer - A system administrator - The Hardware Blame someone else but don’t fix it
- 13. How to blame the PHP code? Don’t measure the time, measure the code quality. The quality from performance perspective, not OOD
- 14. Why is a PHP application slow? - PHP - PHP 7 twice as fast as the same code on PHP 5.6 - Framework - Symfony 4 twice as fast as the same code on Symfony 3.4
- 15. because of SQL
- 16. Step #2 Let’s measure bad SQL with Symfony toolbar extension - Hydration time - Slow with a lot of joins - Queries count - Duplicate queries count - same queries with different params - Identical queries count - Same queries - Performance tab - time based
- 18. Extend performance tab metrics
- 19. Extend performance tab metrics @debug.stopwatch
- 20. Step #2.1 Repeat the same for all network operations if they affect performance: - External API calls count - Redis cache requests count - Filesystem access count - Memory usage by application or better the method - etc. count
- 21. Issue #2 Developers don’t check Toolbar
- 22. Step #3 Integrate query metrics with test framework
- 23. Test query metrics only on real or real-life data.
- 24. Issue #3 Now PHP and Framework usage is a bottleneck
- 25. Symfony Toolbar Main Issue Symfony developer toolbar adds overhead by itself and can’t be used in production So it can’t be used for real precise profiling
- 26. Step #4 Choose the tool for profiling PHP code. - xDebug - good start, but it’s not a profiler - Xhprof - very basic functionality, only time and memory - Blackfire - fork of Xhprof, widely used, a lot of integrations - free plan has all xhprof features in a fancy interface, paid plans bring a lot of features - Tideways - fork of Xhprof - Very similar to blackfire by the feature list but not so common
- 27. Blackfire pros - Low overhead * - Can be used in production - A lot of ways to use, from CURL to Player - Profile comparing - Sharing - Cross platform support - Testing by all the metrics - Periodic builds on production - Profile every N request on overloaded application
- 28. Blackfire cons - Most of features only available with paid plans. - The big overhead on new PHP versions. - Interface not always intuitive. - *Requires prod-like environment.
- 33. Defining custom metrics at Blackfire
- 34. Blackfire Tests Can replace some generic Symfony profiler based tests
- 35. Blackfire SDK
- 38. Validate environment configuration - bin/symfony_requirements - bin/console doctrine:ensure-production-settings - bin/console oro:check-requirements - Blackfire configs
- 39. What else?
- 40. Xdebug extension to check Garbage Collector efficiency
- 41. Logging Monolog Processors to enrich log messages ● Elapsed memory ● Current memory ● Peak memory ● Time taken ● Channels
- 43. Collecting Logs
- 44. Logs Monitoring
- 45. To summarize Metrics can be used for: - Local profiling - CI tests - Production testing - Load testing
- 46. To summarize To make a developer follow metrics: - Make every metric explicit and as small as possible - Describe the value of all the metrics and how to fix them - Don’t rely on time or other unstable metrics - Don’t add tests to common metrics that you don’t know how to fix
- 47. To summarize - Symfony Toolbar and Blackfire are best friends of profiling - xDebug could help too but be carefull - Logging helps to “profile” in production
- 48. Questions