Need for Speed: Removing speed bumps from your Symfony projects ⚡️

No one wants their application to drag like a car stuck in the slow lane! Yet it’s all too common to encounter bumpy, pothole-filled solutions that slow the speed of any application. Symfony apps are not an exception.
In this talk, I will take you for a spin around the performance racetrack. We’ll explore common pitfalls - those hidden potholes on your application that can cause unexpected slowdowns. Learn how to spot these performance bumps early, and more importantly, how to navigate around them to keep your application running at top speed.
We will focus in particular on tuning your engine at the application level, making the right adjustments to ensure that your system responds like a well-oiled, high-performance race car.

1. Need for Speed
Removing speed bumps from your Symfony projects

2. Introduction

3. Weavers, Sylius

4. Why do we need to thinks
about performance?

5. ~ Amazon
“100ms Faster
=
1% More Revenue.”

7. How?

8. Let’s start!

9. The most common performance bottlenecks
0
15
30
45
60
Amount of queries to DBCost of object serialization Latency Framework 54
28
56
Votes

10. Base

11. Algorithmic complexity

12. O(M) vs O(MN) vs O(M^2)

14. That’s why we usually forget
about it :/

15. Measure!

16. Understanding of tools

17. Tools are generally performant
But Your case is different

18. Project structure

20. Database turn

21. N+1

22. Product list

23. Let’s start small
{
"@context":"/api/contexts/Product",
"@id":"/api/products",
"@type":"hydra:Collection",
"hydra:totalItems":6,
"hydra:member":[
{
"@id":"/api/products/1",
"@type":"Product",
"id":1,
"name":"T-Shirt",
"price":1000
},
{
"@id":"/api/products/2",
"@type":"Product",
"id":2,
"name":"Trousers",
"price":5000
},
{
"“…“":"“…“"
}
]
}
Amount of products: 6
No associations between objects
Sample query on the left

25. O(1)

26. Order list

27. How many queries are executed here?
{
"@context": "/api/contexts/Order",
"@id": "/api/orders",
"@type": "hydra:Collection",
"hydra:totalItems": 3,
"hydra:member": [
{
"@id": "/api/orders/1",
"@type": "Order",
"id": 1,
"orderItems": [
"/api/order_items/1",
"/api/order_items/2"
]
},
{
“…”: “…“
}
]
}
Amount of orders: 3
Every order associated with 2 items
Sample query on the left
No total field

30. O(M)

31. Order list with additional field

32. How many queries are executed here?
{
"@context": "/api/contexts/Order",
"@id": "/api/orders",
"@type": "hydra:Collection",
"hydra:totalItems": 3,
"hydra:member": [
{
"@id": "/api/orders/1",
"@type": "Order",
"id": 1,
"orderItems": [
"/api/order_items/1",
"/api/order_items/2"
],
"total": 7000
},
{
“…”: “…“
}
]
}
Amount of orders: 3
Every order associated with 2 items
Sample query on the left
Added “total()” as a function of product
price and quantity of item

34. O(M*N) or O(M^2) !

37. How to spot it?

39. How to fix it?

40. Solution 1

41. #[ORM\OneToMany(fetch: ‘LAZY')]
#[ORM\OneToMany(fetch: ‘EXTRA_LAZY')]
#[ORM\OneToMany(fetch: ‘EAGER')]
What is the difference between them?

42. #[ORM\OneToMany(fetch: ‘LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EXTRA_LAZY')] => ???
#[ORM\OneToMany(fetch: ‘EAGER')] => ???

43. #[ORM\OneToMany(fetch: ‘LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EAGER')] => ???

44. #[ORM\OneToMany(fetch: ‘LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EAGER')] => 9

46. #[ORM\OneToMany(fetch: ‘LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EAGER')] => 9
#[ORM\OneToMany(fetch: ‘EAGER')] => 5 (OrderItem and Product)

48. #[ORM\OneToMany(fetch: ‘LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORM\OneToMany(fetch: ‘EAGER')] => 5
#[ORM\OneToMany(fetch: ‘EAGER')] (OrderItem and Product) + Serialisation groups => 4

50. But….

51. Solution 2

52. $this->createQueryBuilder('o')
->addSelect('oi', 'p')
->join(OrderItem::class, 'oi', Join::WITH, 'oi.originOrder = o')
->join(Product::class, 'p', Join::WITH, 'oi.product = p')
;

54. So is single query an ultimate
solution?

55. ⚠ Put the brakes on ⚠

56. Joins are expensive #

57. Process of
serialisation

58. Serialisation process
oversimplified

59. [
'id' => 1,
'name' => 'T-Shirt',
'price' => '1000'
]
Application
Database

60. [
'id' => 1,
'name' => 'T-Shirt',
'price' => '1000'
]
Hydration $
new Product()
Application
Database

61. [
'id' => 1,
'name' => 'T-Shirt',
'price' => '1000'
]
Hydration $
new Product()
Application
Serialization ⚙
{
‘id': 1,
‘name': 'T-Shirt',
‘price': '1000'
}
Database Frontend app

62. [
'id' => 1,
'name' => 'T-Shirt',
'price' => '1000'
]
Hydration $
new Product()
Application
Serialization ⚙
{
‘id': 1,
‘name': 'T-Shirt',
‘price': '1000'
}
Database Frontend app
&

63. Fullstack vs Headless

64. Usefulness of laziness

65. Profile Total time Network timeMemory usage Amount of queries
Reference build 1.1 s 562 ms 32.9 MB 500 ms / 134 rq
Profile with leftjoin 813 ms 511 ms 16.6 MB 456 ms / 54 rq
Profile with lazy translations833 ms 502 ms 27.3 MB 446 ms / 54 rq

66. Lazy vs Extra_Lazy

67. Straight of good
design

68. Huge objects are problem

69. Different representations

70. Minimising unnecessary
operations

71. Read model
shortcut

72. Saving data to different models

73. PUT REQUEST

74. Pre-computing

77. Sylius order

79. Saving read-optimised objects

80. Read models doesn’t have to
be models '

81. 1. Store read models in key-value storage
2. Restore it by indexed key

82. Use “SELECT NEW” syntax

83. $query = $this->_em->createQuery(
'SELECT NEW OrderItemDTO(SUM(oi.quantity * p.price) FROM OrderItem oi JOIN oi.product p ’
);
$query->getResult(); // array of OrderItemDTO

84. Summary

86. Remember about algorithmic complexity of your queries
Do not hydrate too much data
Think out of the box of your “entities”

88. Thank you!