Performance analyseren in Vendure

Performance debugging is lastig: het vereist kennis en inzicht in zowel applicatiecode als infrastructuur. Maar waar moet je beginnen met zoeken? Dit is geen volledige gids die alle performanceproblemen oplost, maar hopelijk helpt het je om te vinden waar je kunt beginnen.

Isoleer het probleem

De eerste stap is om het probleem te isoleren. Zet je aannames opzij en controleer eerst waar het probleem zich bevindt:

1. Kun je het probleem reproduceren met alleen de GraphQL query, of zit het probleem in de Admin UI?
2. Kun je het probleem oplossen door velden uit de query te verwijderen? Zo ja, dan ligt het probleem waarschijnlijk in custom fields of custom field resolvers.
3. Als het verwijderen van velden het probleem niet oplost, kun je het loggen van alle database queries in TypeORM inschakelen.
4. Als deze stappen niet werken, draai je Vendure server dan lokaal en begin met debuggen. Of voeg simpelweg overal console.log() toe in node_modules om de foutieve code te vinden.
5. Pas nadat je deze stappen hebt doorlopen, moet je kijken naar resources zoals RAM en CPU. Vendure is gebouwd met performance in gedachten, dus meestal zijn resources niet het probleem.

Het ideale resultaat is dat je het probleem lokaal kunt reproduceren op een lokale database, zonder externe factoren zoals live verkeer of achtergrond processen.

Veelvoorkomende oorzaken

Hieronder vind je de meest voorkomende oorzaken van een trage Vendure instance.

Custom Code

Extensibiliteit is geweldig, maar het stelt je ook in staat dingen makkelijk stuk te maken. Vendure heeft veel strategieën om je eigen businesslogica te definiëren, vaak met de mogelijkheid om asynchrone code uit te voeren binnen die strategieën.

Als ontwikkelaar moet je weten waar deze strategieën worden gebruikt. Sommige strategieën worden meerdere keren aangeroepen tijdens een enkele add to cart actie. Stel je voor dat je zes keer een verzoek naar een externe API doet, telkens wanneer een klant een product aan de winkelwagen toevoegt.

Een veelgemaakte fout is het plaatsen van zware code in een van deze onderdelen van Vendure:

• Custom Promotions - De promoties op een order worden opnieuw berekend bij elke wijziging aan een order.
• Order Interceptors - Zoals de naam al aangeeft, worden deze interceptors aangeroepen bij elke actie om een item toe te voegen of te verwijderen uit de winkelwagen.

Custom Fields

Custom Fields zijn een krachtige functie van Vendure, maar kunnen je server vertragen als ze verkeerd worden gebruikt.

1. Custom relationele velden met eager loading. Wanneer een relationeel custom field wordt ingesteld op eager: true, zal TypeORM een SQL query genereren die altijd een join maakt met je custom field. Probeer eager loading te vermijden en gebruik het alleen wanneer het strikt noodzakelijk is.

GraphQL Field Resolvers

GraphQL Field Resolvers zijn een geweldige manier om een waarde op een willekeurige entiteit te bepalen. Je kunt bijvoorbeeld het veld relatedProduct toevoegen aan een Product, en in de resolver een database query uitvoeren om gerelateerde producten op te halen.

Dit kan leiden tot het beruchte N+1 probleem. In een lijstquery waarin je tien producten ophaalt, heb je nu mogelijk tien extra databasecalls nodig om de gerelateerde producten op te halen. Je kunt Dataloader gebruiken om dit probleem te voorkomen.

Storefront Queries

We zien vaak dat de storefront één grote GraphQL query gebruikt om bijvoorbeeld een productdetailpagina te renderen. Hoewel hergebruik van queries in code handig is, haal je waarschijnlijk veel velden op die niet gebruikt worder op de PDP. Enkele tips:

• Haal alleen de velden op daadwerkelijk op de huidige pagina weergegeven worden.
• Sla globale data zoals collecties op in een cache, zodat je niet alle collecties en onderliggende collecties hoeft op te halen bij elke paginaweergave voor de navigatie.

Er zijn complexere scenario's dan dit, maar ik hoop dat dit je in de juiste richting wijst. Meestal werkt Vendure probleemloos, maar een periodieke Vendure audit is nooit een slecht idee!