Navigatie

Webshop leveranciers optimalisatie Onderhoud

Een groothandel webshop houder, maakt op zijn beurt gebruik van leveranciers, waarbij beschikbaarheid/voorraad en prijs kan verschillen per product/leverancier. Standaard gebeurde leverancier-keuze op basis van goedkoopste levering, als ook logischerwijs aanwezige voorraad.

Opdrachtgever:
Op aanvraag
Talen:
PHP
Oplevering:
Zomer 2017
Webshop leveranciers optimalisatie

De leverprijs hoefde als factor echter een minder grote rol te spelen, wanneer het mogelijk zou zijn om het aantal leveranciers te beperken. Dit heeft als gevolg dat er in leveringskosten gesneden kan worden. Uiteraard diende deze rekenmethode wel aan enkele clausules, zoals maximale afwijkingen ten opzichte van goedkoopst leverbaar product, te voldoen.

Voor dit onderdeel binnen de webshop, heeft men mij benaderd. Binnen de export-optie van Magento heb ik enkele functies ingevoegd die gebruik maakt van de PHP collections van Magento, om vervolgens alle mogelijke combinaties van product/leverancier, per bestelling te bepalen. Enkel dan ben je in staat, om op basis van de verschillende clausules/reken-wensen ook de meest efficiente levering(sproces) te achterhalen.

Dit onderdeel was op zichzelf geslaagd. Alle combinaties werden vooraf opgezet, niet mogelijke leverings-combinaties (bijvoorbeeld doordat een leverancier een specifiek product niet heeft) werden direct genegeerd, en uiteindelijk rolde de beste optie uit de bus, met zo weinig mogelijk betrokken leveranciers.

PHP geheugen in de gigabytes

Echter, doordat er bij een bestelling van 20 producten, cummulatief te leveren door bijvoorbeeld 5 verschillende leveranciers al 3.2 miljoen mogelijke leverings-combinaties als gevolg had, en bij bijvoorbeeld 6 leveranciers al 64 miljoen, kon het benodigd geheugen in de gigabytes schieten. Alhoewel men zelf invloed had op het geheugen-limiet, was dit geen werkbare situatie.

Hierop heb ik een wiskundige benaderd, die zijn tanden er flink in heeft gezet. Door een meer wiskundige benadering van PHP's while-loops, wist hij op papier tot een verbeterde oplossing te komen van mijn implementatie, waarna we zijn op papier uitgeschreven pseudo-code, hebben omgezet in PHP.

Alhoewel de oplossing achteraf eenvoudig klonk, bezorgde het resultaat ons een glimlach op onze gezichten. De nieuwe oplossing voorkwam enig benodigd geheugen. Hoe groot de producten tot de macht leveranciers-som ook werd, het geheugen bleef te allen tijde op 0MB uitkomen, en werd bovendien door andere efficiënte toepassingen (door bepaalde resultaten te hergebruiken) in minder dan 0.05 seconden afgehandeld (test gedaan bij 4 tot de macht 11 mogelijkheden = 4.19 miljoen).

Reken-regels

De beste combinatie moest wel aan enkele clausules c.q. reken-regels voldoen. De prijs-afwijking per product voor de meest optimale leveringsproces, mocht bijvoorbeeld niet groter zijn dan 10% ten opzichte van de goedkoopst te leveren product. Ook moest rekening worden gehouden met bezorgkosten per unieke leverancier, als ook eventuele gratis bezorgkosten per leverancier vanaf een bepaald bedrag.

Dit had als gevolg, dat we van de eventueel miljoenen combinaties, op zijn minst een lijst van kanshebbers bij moesten houden om in een tweede fase nog eens tegen elkaar af te zetten om de PHP reken regels op los te laten. Gevolg was dat voor deze lijst (PHP array) op zich, alsnog veel PHP geheugen nodig zou zijn.

Ook dit hebben we weten te reduceren, waarbij de lijst enkel zo groot kan worden als het aantal mogelijke leveranciers. Hierdoor is de benodigde lengte/grootte van de lijst reeds vooraf bekend, en weet je dus vooraf of het geheugen-issues met zich mee zal brengen. Bij 1 miljoen leveranciers zou dit alsnog slechts 50MB geheugen vergen. Te overzien, maar bovendien tijd voor een feest wanneer er een dusdanige bestelling met 1 miljoen benodigde leveranciers binnen komt!