Versnel de verwerking van exchange calls

Deze blog beschrijft de oorzaak van exchange vertragingen en de mogelijke oplossing hiervan. Deze blog is geschreven voor gevorderde ontwikkelaars.

De meeste exchange calls worden parallel aan de actie uitgevoerd, waardoor trage exchange calls geen invloed hebben op de ervaring van uw eindgebruiker. Het maakt voor uw systeem niet uit of deze aanroep een paar seconden later komt.

Een uitzondering is de exchange call die een succesvolle betaling doorgeeft. Deze wordt door ons direct verstuurd als een betaling geslaagd is. Indien wij deze niet direct versturen en uw exchange traag is, kan het voorkomen dat uw gebruiker nog voordat de betaling verwerkt is terug komt op uw website. Bij een trage exchange dient uw bezoeker te wachten totdat deze is voltooid. Dus als uw server er 3 seconden over doet, dient de bezoeker ook 3 seconden te wachten wat voor een negatieve gebruikerservaring zorgt.

Nadelige gevolgen van een trage exchange:

  1.   Uw klant moet wachten na zijn betaling.
  2.   De status op de bevestigingspagina in uw shop is niet op up to date.
  3.   Het retry scheme zorgt voor meer aanroepen.
  4.   Uw systeem mist betaalstatussen.
  5.   U ontvangt van Pay.nl (veel) e-mails met errors.
  6.   U moet transactiestatussen handmatig herstellen.

Ondersteuning nodig?

Komt u er met de onderstaande informatie niet uit? Vanaf het Businesspakket is het mogelijk dat een tweedelijns supportmedewerker u hierbij ondersteunt. U kunt voor technische ondersteuning contact opnemen met onze supportdesk op: +31 (0)88 - 88 666 66 of een e-mail sturen naar: support@pay.nl

Maximale wachttijd?

Wij wachten maximaal 5 seconden op een reactie van uw webshopsysteem. Reageert deze trager op onze aanroep, dan sturen wij uw klant alvast door. Zouden we langer wachten, dan bestaat de kans dat de klant zijn pagina refresht omdat hij denkt dat er een technisch probleem is.

Voor bepaalde klanten kunnen wij deze wachttijd verhogen, bijvoorbeeld als uw systeem altijd 6 seconden over de exchangeverwerking doet en u geen optimalisatie kunt doorvoeren.

Oorzaken waarom uw exchange traag kan zijn:

Uw exchange wordt sinds een bepaalde datum trager

Als de exchange traag is, maar uw hardware voldoende capaciteit heeft, dan vindt u dit probleem vaak binnen uitgevoerde query(s) of disk-IO.

U lost het bovenstaande probleem op door query- en database optimalisatie. Door op de juiste manier gebruik te maken van "KEYS" en "Indexen" kunt u query's en databases optimaliseren. Een query die niet op de door ons voorgestelde manier ontwikkeld is zal bij een kleine database snel zijn. Naarmate een database meer data bevat wordt het zoeken moeilijker en resulteert dit in een hogere load. Vanzelfsprekend duurt de query hierdoor (veel) langer.

Log de querysnelheid of analyseer uw "slow_log". Onderzoek het aantal query's binnen uw exchange op implementatiefouten en herstel deze waar nodig.

Uw exchange is altijd traag geweest

Als uw exchange altijd traag is geweest, onderzoek dan eerst de mogelijkheid of deze sinds een bepaalde datum trager is geworden. Indien dit niet het geval is, dan heeft uw server gewoonweg veel tijd nodig voor de verwerking. Webshopsystemen zoals bijvoorbeeld Magento voeren meerdere acties uit tijdens één (betaal)statuswijziging. Acties zoals het updaten van een orderstatus, het updaten van de voorraad, de creatie van een factuur, het verzenden van deze factuur of het ophalen van externe koppelingen kan ervoor zorgen dat de verwerking langer duurt.

U lost het bovenstaande probleem op door query- en databaseoptimalisatie. Door op de juiste manier gebruik te maken van "KEYS" en "Indexen" kunt u query's en databases optimaliseren. Een query die niet op de door ons voorgestelde manier ontwikkeld is zal bij een kleine database snel zijn. Naarmate een database meer data bevat wordt het zoeken moeilijker en resulteert dit in een hogere load. Vanzelfsprekend duurt de query hierdoor (veel langer).

Log de query snelheid of analyseer uw "slow_log". Onderzoek het aantal query's binnen uw exchange op implementatie fouten en herstel deze waar nodig.

Uw exchange ervaart een periodieke incidentele vertraging

U merkt dat de exchange traag is maar enkel op bepaalde tijden. Omdat de exchange niet altijd traag is zult u meestal geen e-mails van Pay.nl krijgen omdat bij een volgende poging uw techniek weer correct functioneert.

Oplossing: Controleer of uw server een hoge load heeft op het moment dat u een traag werkende exchange ervaart. Neem voor meer informatie en de oplossing contact op met uw Service Provider.

Uw exchange ervaart een plotselinge incidentele vertraging

U krijgt een melding dat uw exchange traag is, als het probleem lang aanhoudt, zult u e-mailnotificaties van ons ontvangen.

Oplossing: Controleer of uw server een hoge load heeft op het moment dat u een traag werkende exchange ervaart. Heeft u mogelijk een wijziging doorgevoerd in uw server of hardware. Herstel dan de wijziging en neem voor ondersteuning contact op met uw Service Provider.

Uw exchange ervaart een vertraging als gevolg van een piek in uw traffic

Is uw systeem traag door een piek in het aantal transacties, dan dient u alert te zijn. Als uw systeem trager wordt is dit een signaal dat uw techniek aan zijn max zit. Optimaliseer uw software of breidt uw hardware uit. Wij zien een situatie als deze vaak bij ticketingpartijen. Als de verkoop van tickets bijvoorbeeld voor een gewild concert of event van start gaat stijgt het aantal transacties op dat moment enorm waardoor de techniek aan zijn limiet zit of eroverheen gaat.

Oplossing: Probeer zoveel mogelijk processen in een queue te plaatsen. Wij raden het af om het versturen van tickets op basis van de exchange te doen. Wij adviseren op basis van de exchange enkel betaalstatussen te updaten in uw database en met een separaat proces de daadwerkelijke tickets te versturen aan uw klant. Heeft u dan een piek van 100 bestellingen, en kunt u 5 tickets per seconde versturen, dan doet u systeem er dus 20 seconden over, waarna alles geregeld is.

 

De Payment State Log

1. U kunt een overzicht opvragen van alle statusupdates of een specifieke data-selectie op basis van filters.
2. Deze widget geeft het percentage mislukte statusupdates weer op basis van uw data selectie.
   
   
3. Deze widget geeft de toegestane gemiddelde reactietijd weer in seconden. Hierbij is 2,5 sec nog acceptabel, hoger dan 5 sec is onacceptabel.
   
   
4. Dit is een grafische weergave van de reactie-tijd op basis van de afgelopen 36 uur. De legenda geeft de verschillende grafieken weer.
   
   
5. In dit overzicht ziet u elke specifieke status update op basis van uw data selectie. U kunt elke status update openen door op "Details" te klikken.

 

Drie handige tips

1. Een query mag best traag zijn maar alleen als deze altijd traag is geweest. Indien u een simpele actie uitvoert zoals bijvoorbeeld het uitvoeren van een exchange, dan mag dit geen invloed hebben op uw techniek. In principe hoeft u binnen een exchange alleen te weten dat er statuswijziging heeft plaatsgevonden. Alle andere processen kunnen daarna via een queue plaatsvinden.

1. Gebruik monitoringtools zoals New Relic. Met New Relic kunt u tot in detail trage processen analyseren. Er wordt onderscheid gemaakt in server-IO, conecties, memory, querys, software-functies en netwerk. Zo kunt u precies zien waar binnen het proces de vertraging ontstaat.
   
   
2. Zorg voor een implementatie die optimaal functioneert en die eventuele verstoringen binnen het retry-scheme zelf oplost zodat u geen handmatige acties uit hoeft te voeren. Het is mogelijk meerdere exchanges te gebruiken in combinatie met een externe (logging) server.

 

Let op!

Indien uw webshopsysteem en techniek onvoldoende geoptimaliseerd is en wij hierdoor veel extra acties moeten uitvoeren kan er een toeslag berekend worden of kan de overeenkomst eenzijdig versneld beëindigd worden.