Need for Speed: Removing speed bumps in API Projects

Łukasz Chruściel
Łukasz ChruścielAPI Designer à Commerce Weavers
Need for Speed
Removing speed bumps in API Projects
Introduction
Weavers, Sylius, API Platform
Why do we need to thinks
about performance?
~ Amazon
“100ms Faster
=
1% More Revenue.”
Need for Speed: Removing speed bumps in API Projects
How?
Let’s start!
The most common performance bottlenecks
0
15
30
45
60
Amount of queries to DB Cost of object serialization Latency Framework
5
4
28
56
Votes
Base
Algorithmic complexity
O(M) vs O(MN) vs O(M^2)
Need for Speed: Removing speed bumps in API Projects
That’s why we usually forget
about it :/
Measure!
Understanding of tools
Tools are generally performant
But Your case is different
Project structure
Need for Speed: Removing speed bumps in API Projects
Database turn
N+1
Product list
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
Need for Speed: Removing speed bumps in API Projects
O(1)
Order list
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
fi
eld
Need for Speed: Removing speed bumps in API Projects
Need for Speed: Removing speed bumps in API Projects
O(M)
Order list with additional
fi
eld
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
Need for Speed: Removing speed bumps in API Projects
O(M*N) or O(M^2) 🚀
Need for Speed: Removing speed bumps in API Projects
How to spot it?
Need for Speed: Removing speed bumps in API Projects
How to
fi
x it?
Solution 1
#[ORMOneToMany(fetch: ‘LAZY')]
#[ORMOneToMany(fetch: ‘EXTRA_LAZY')]
#[ORMOneToMany(fetch: ‘EAGER')]
What is the difference between them?
#[ORMOneToMany(fetch: ‘LAZY')] => 11
#[ORMOneToMany(fetch: ‘EXTRA_LAZY')] => ???
#[ORMOneToMany(fetch: ‘EAGER')] => ???
#[ORMOneToMany(fetch: ‘LAZY')] => 11
#[ORMOneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORMOneToMany(fetch: ‘EAGER')] => ???
#[ORMOneToMany(fetch: ‘LAZY')] => 11
#[ORMOneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORMOneToMany(fetch: ‘EAGER')] => 9
Need for Speed: Removing speed bumps in API Projects
#[ORMOneToMany(fetch: ‘LAZY')] => 11
#[ORMOneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORMOneToMany(fetch: ‘EAGER')] => 9
#[ORMOneToMany(fetch: ‘EAGER')] => 5 (OrderItem and Product)
Need for Speed: Removing speed bumps in API Projects
#[ORMOneToMany(fetch: ‘LAZY')] => 11
#[ORMOneToMany(fetch: ‘EXTRA_LAZY')] => 11
#[ORMOneToMany(fetch: ‘EAGER')] => 5
#[ORMOneToMany(fetch: ‘EAGER')] (OrderItem and Product) + Serialisation groups => 4
Need for Speed: Removing speed bumps in API Projects
Solution 2
final class LoadItemsAndProductsExtension implements QueryCollectionExtensionInterface,
QueryItemExtensionInterface
{
private function apply(QueryBuilder $queryBuilder): void
{
$queryBuilder
->addSelect('oi', 'p')
->join(OrderItem::class, 'oi', Join::WITH, 'oi.originOrder = o')
->join(Product::class, 'p', Join::WITH, 'oi.product = p')
;
}
}
Need for Speed: Removing speed bumps in API Projects
But….
{
"@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
},
{
"@id": "/api/order_items/1",
"@type": "OrderItem",
"id": 1,
"product": "/api/products/1",
"quantity": 2,
"originOrder": "/api/orders/1",
"price": 2000
},
{
"@id": "/api/products/1",
"@type": "Product",
"id": 1,
"name": "T-Shirt",
"price": 1000
},
{
"@id": "/api/order_items/2",
"@type": "OrderItem",
"id": 2,
"product": "/api/products/2",
"quantity": 1,
"originOrder": "/api/orders/1",
"price": 5000
},
{
“…”: “…”
}
]
}
Solution 3
class OrderCollectionProvider implements ProviderInterface
{
public function __construct(private readonly OrderRepository $orderRepository)
{
}
public function provide(
Operation $operation,
array $uriVariables = [],
array $context = []
): object|array|null {
return $this->orderRepository->findWithItemsAndProducts();
}
}
public function findWithItemsAndProducts()
{
return $this->createQueryBuilder('o')
->addSelect('oi', 'p')
->leftJoin('o.orderItems', 'oi')
->leftJoin('oi.product', 'p')
->getQuery()
->getResult();
}
Need for Speed: Removing speed bumps in API Projects
But….
So is single query an ultimate
solution?
⚠ Not so fast ⚠
Joins are expensive 💰
Hydration 🧙
Fetch
[
'id' => 1,
'name' => 'T-Shirt',
'price' => '1000'
]
Hydration 🧙
new Product()
Database Application
More data you fetch
||
/
More you hydrate
Perfect size of micro service?
Perfect amount of queries?
Fetch as much as you have to
But not more
Proper de
fi
nition of
fi
elds
Float vs double
Decimal ->
fi
xed-point precision
Float ->
fl
oating-point precision
How many updates are executed?
Product has a
fl
oat price
fi
eld de
fi
ned as
fl
oat
Order item quantity has been changed by 1
During which we will read data from Product
How many updates are executed?
How many updates are executed?
Product has a
fl
oat price
fi
eld de
fi
ned as decimal
Order item quantity has been changed by 1
During which we will read data from Product
How many updates are executed?
How many updates are executed?
Know your tool!
Custom cars APIs are the
fastest
Serialisation twists
We are reducing network
connections on expanse of object
size/db connections 🤨
Atomic objects (Edge Side API)
{
"@context": "/api/contexts/Order",
"@id": "/api/orders/1",
"@type": "Order",
"id": 1,
"orderItems": [
{
"@id": "/api/order_items/1",
"@type": "OrderItem",
"product": "/api/products/1",
"quantity": 4
},
{
"@id": "/api/order_items/2",
"@type": "OrderItem",
"product": "/api/products/2",
"quantity": 1
}
],
"total": 9000
}
{
"@context": "/api/contexts/Order",
"@id": "/api/orders/1",
"@type": "Order",
"id": 1,
"orderItems": [
{
"@id": "/api/order_items/1",
"@type": "OrderItem",
"product": {
"@id": "/api/products/1",
"@type": "Product",
"name": "test2",
"price": 1000
},
"quantity": 4
},
{
"@id": "/api/order_items/2",
"@type": "OrderItem",
"product": {
"@id": "/api/products/2",
"@type": "Product",
"name": "Trousers",
"price": 5000
},
"quantity": 1
}
],
"total": 9000
}
Atomic objects (Edge Side API)
Partial serialisation
{
"@context": "/api/contexts/Order",
"@id": "/api/orders/1",
"@type": "Order",
"id": 1,
"orderItems": [
{
"@id": "/api/order_items/1",
"@type": "OrderItem",
"product": "/api/products/1",
"quantity": 4
},
{
"@id": "/api/order_items/2",
"@type": "OrderItem",
"product": "/api/products/2",
"quantity": 1
}
],
"total": 9000
}
{
"@context": "/api/contexts/Order",
"@id": "/api/orders/1",
"@type": "Order",
"id": 1,
"orderItems": [
{
"@id": "/api/order_items/1",
"@type": "OrderItem",
"product": {
"@id": "/api/products/1",
"@type": "Product",
"name": "test2",
"price": 1000
},
"quantity": 4
},
{
"@id": "/api/order_items/2",
"@type": "OrderItem",
"product": {
"@id": "/api/products/2",
"@type": "Product",
"name": "Trousers",
"price": 5000
},
"quantity": 1
}
],
"total": 9000
}
Atomic objects (Edge Side API)
Partial serialisation
Spare
fi
elds
Straight of good
design
Huge objects are problem
Different representations
Minimising unnecessary
operations
Read model
shortcut
Saving data to different models
PUT REQUEST
Pre-computing
Need for Speed: Removing speed bumps in API Projects
Need for Speed: Removing speed bumps in API Projects
Sylius order
Sylius order
Need for Speed: Removing speed bumps in API Projects
Saving serialised objects
Read models doesn’t have to
be models 🤯
1. Store read models in key-value storage
2. Restore it by indexed key
Summary
Need for Speed: Removing speed bumps in API Projects
Remember about algorithmic complexity of your queries
Do not hydrate too much data
Think about the box of your “entities”
Thank you!
1 sur 104

Contenu connexe

Similaire à Need for Speed: Removing speed bumps in API Projects(20)

Dernier(20)

Green Leaf Consulting: Capabilities DeckGreen Leaf Consulting: Capabilities Deck
Green Leaf Consulting: Capabilities Deck
GreenLeafConsulting170 vues
ChatGPT and AI for Web DevelopersChatGPT and AI for Web Developers
ChatGPT and AI for Web Developers
Maximiliano Firtman152 vues
The Research Portal of Catalonia: Growing more (information) & more (services)The Research Portal of Catalonia: Growing more (information) & more (services)
The Research Portal of Catalonia: Growing more (information) & more (services)
CSUC - Consorci de Serveis Universitaris de Catalunya51 vues

Need for Speed: Removing speed bumps in API Projects