Resultaten van een zoekprofiel mailen

[Dutch_guy]

Ik heb ooit een script gemaakt waarbij gebruikers aan de hand van eigen zoekcriteria regelmatig een mail krijgen met de resultaten van hun zoekopdracht.

Het gaat in dit geval om boten. Bijna dagelijks worden er nieuwe boten geplaatst op de website.

1x per dag draait het script welke van ieder zoekprofiel nagaat of die boot past binnen iemand zijn zoekopdracht. Zo ja, dan wordt die boot gemaild naar de gebruiker. Dat kunnen meerdere boten per mail zijn.

Nu is het zo dat het aantal gebruikers alleen maar toeneemt en dit script niet meer toereikend is.

Hoe kan ik dit efficiënter aanpakken? Hoe doet een partij als Marktplaats dit bijvoorbeeld met de zoekopdrachten die je kan opslaan en die dan naar je gemaild worden.

Op dit moment loop ik eerst alle zoekprofielen af of er een match is, terwijl ik volgens mij vanuit de boot moet kijken wie zijn zoekprofiel overeenkomt. Daarbij komt het dus voor dat iemand in 1 mail 2 of meerdere boten ontvangt.

Iemand die mij in de juiste richting kan krijgen?

[GlowMouse]

Kijken vanuit de boot of vanuit de gebruiker maakt niets uit. Het aantal keer dat je vergelijkt is in beide gevallen het aantal gebruikers maal het aantal boten. Zorg dat je efficiënter kunt vergelijken (kun je voor een boot al snel veel gebruikers wegstrepen of andersom?), doe de vergelijking gedurende de dag terwijl de boten worden toegevoegd, of smeer het werk uit over meerdere cores of processors.

[Dutch_guy]

Het moet wel echt 1x per dag gebeuren. Stel dat er op een dag 10 boten worden toegevoegd, en die vallen allemaal binnen iemand zijn profiel, dan zou die persoon 10 mails krijgen, dat willen we niet.

[GlowMouse]

Dutch_guy schreef op donderdag 6 juni 2019 @ 16:22:
Het moet wel echt 1x per dag gebeuren. Stel dat er op een dag 10 boten worden toegevoegd, en die vallen allemaal binnen iemand zijn profiel, dan zou die persoon 10 mails krijgen, dat willen we niet.

Oh, is er geen mogelijkheid om het resultaat van de vergelijking maximaal 24 uur te bewaren om ze in een enkel mailtje te bundelen? Dat beperkt de mogelijkheden wel flink.

[TheRookie]

Heb je de beschikking over een database ?

Een script dat 1x per uur draait en een (tijdelijke) tabel met de match tussen de boot en de user vult.
Vervolgens 1x per dag die tabel uitlezen om de mail te vullen en de tabel weer leeg te gooien.

[edit]
Dit zou (afhankelijk van de schaal) zelfs nog met losse textfiles per user oid kunnen

[ Voor 16% gewijzigd door TheRookie op 06-06-2019 16:29 ]

[Dutch_guy]

GlowMouse schreef op donderdag 6 juni 2019 @ 16:24:
[...]

Oh, is er geen mogelijkheid om het resultaat van de vergelijking maximaal 24 uur te bewaren om ze in een enkel mailtje te bundelen? Dat beperkt de mogelijkheden wel flink.

Jawel, dat kan wel ik begreep je verkeerd.

[Reptile209]

Luie oplossing: bij een match stuur je een generieke mail naar de gebruiker met een link naar zijn zoekpagina. Bewaar een flag dat je al gemaild hebt (timestamp). Bij een volgende match doe je niks meer.
M.a.w.: je mailt niet alle resultaten, maar alleen een mailtje dat er 1 of meer matches zijn.

[Freeaqingme]

Dutch_guy schreef op donderdag 6 juni 2019 @ 16:03:
Nu is het zo dat het aantal gebruikers alleen maar toeneemt en dit script niet meer toereikend is.

Hoe werkt het nu en wat/waarom is het niet meer toereikend?

[DennusB]

Ik zou kijken naar serverless op bijvoorbeeld AWS. Maak een Lambda die je triggert op het moment dat iemand een nieuwe boot plaatst bijvoorbeeld. Of draai die Lambda gewoon 1x per dag!

[Freeaqingme]

DennusB schreef op donderdag 6 juni 2019 @ 16:56:
Ik zou kijken naar serverless op bijvoorbeeld AWS. Maak een Lambda die je triggert op het moment dat iemand een nieuwe boot plaatst bijvoorbeeld. Of draai die Lambda gewoon 1x per dag!

Ik snap dit advies niet. We weten 0.0 over het platform waar het nu op draait en wat de bottlenecks zijn. Waarom (en hoe) raad je dan een specifiek platform aan?

[Kalentum]

Mogelijke oplossingsrichtingen: kijken in hoeverre zoekopdrachten dubbel voorkomen. Dus ontdubbelen van de zoekopdrachten. Dan kan je voor elke zoekopdracht 1 mail samenstellen en die dan mailen naar een aantal users tegelijk. Hangt er natuurlijk vanaf hoe complex die zoekopdrachten zijn.

Of zoals eerder gemeld: na het plaatsen van een nieuwe boot kijken welke profielen matchen en die alvast opslaan in een tijdelijke tabel (dus boot_id en user_id). Mails versturen, tabel leeggooien. Lijkt me wel typisch iets wat je in een job server of cronjob wilt afhandelen.

Of je kan je zoekprofiel script parallel laten draaien. Dus 4 cronjobs die allemaal een bepaald deel van de users verwerken (bv job 1 doet usernames die beginnen met een A tot en met F, job 2 G tot en met M etcetera). Of parallelliseren door threads te gebruiken.

[DennusB]

Freeaqingme schreef op donderdag 6 juni 2019 @ 17:11:
[...]


Ik snap dit advies niet. We weten 0.0 over het platform waar het nu op draait en wat de bottlenecks zijn. Waarom (en hoe) raad je dan een specifiek platform aan?

Als iemand zo weinig informatie krijgt dan krijg je ook generiek advies. T klinkt een beetje als een cronjob die ergens draait, en als je tegenwoordig schaalbaar wil zijn(wat TS aangeeft) kan je beter naar cloud-native gaan kijken.

[Freeaqingme]

DennusB schreef op vrijdag 7 juni 2019 @ 14:45:
[...]


Als iemand zo weinig informatie krijgt dan krijg je ook generiek advies. T klinkt een beetje als een cronjob die ergens draait, en als je tegenwoordig schaalbaar wil zijn(wat TS aangeeft) kan je beter naar cloud-native gaan kijken.

Maar de vraag was conceptueel van aard. Het cronmechanisme zelf zal zeer vermoedelijk niet de bottleneck zijn. Ik ben het helemaal met je eens dat er weinig informatie voorhanden is, maar dan is 't wel heel gek om specifieke oplossingen (van niet-conceptuele aard) aan te raden.

Ik zie een trend onder (veelal junior of medior) developers die op voorhand willen gaan voor Docker/Kubernetes/etc. Dat kan een prima oplossing zijn, maar je haalt je ook wel extra abstractielagen op de hals die lastiger te troubleshooten en monitoren zijn. Voor >95% van de projecten zal een enkele VPS volstaan.

[ Voor 0% gewijzigd door Freeaqingme op 07-06-2019 14:51 . Reden: s/99%/>95%/g ]

[DennusB]

Freeaqingme schreef op vrijdag 7 juni 2019 @ 14:49:
[...]

Ik zie een trend onder (veelal junior of medior) developers die op voorhand willen gaan voor Docker/Kubernetes/etc. Dat kan een prima oplossing zijn, maar je haalt je ook wel extra abstractielagen op de hals die lastiger te troubleshooten en monitoren zijn. Voor >95% van de projecten zal een enkele VPS volstaan.

Ten eerste ben ik geen junior of medior en ten tweede had ik niet over containers maar over serverless Das ook een concept opzich.

[Dutch_guy]

Er draait inderdaad dagelijks een cronjob. Dit is op dit moment nog een classic ASP script, maar wordt een PHP script.

Het script werkt, maar het loopt regelmatig vast. Er gebeurt ook van alles, de matching, mailen van de resultaten, wegschrijven van regels naar een XML bestand en daarnaast ook nog eventuele prijswijzigingen van boten binnen het zoekprofiel.

Maar ik heb zeker weer ideeën opgedaan, voornamelijk het gebruik van een tijdelijke tabel zal veel voordelen gaan bieden.

[GlowMouse]

Vastlopen is iets wat je moet kunnen debuggen. Zonder het 'vastlopen' goed te begrijpen, is elke oplossing een wilde gok.

[kwaakvaak_v2]

Dutch_guy schreef op vrijdag 7 juni 2019 @ 15:50:
Er draait inderdaad dagelijks een cronjob. Dit is op dit moment nog een classic ASP script, maar wordt een PHP script.

Het script werkt, maar het loopt regelmatig vast. Er gebeurt ook van alles, de matching, mailen van de resultaten, wegschrijven van regels naar een XML bestand en daarnaast ook nog eventuele prijswijzigingen van boten binnen het zoekprofiel.

Maar ik heb zeker weer ideeën opgedaan, voornamelijk het gebruik van een tijdelijke tabel zal veel voordelen gaan bieden.

Dat klinkt als iets wat je wilt opdelen in meerdere taken ipv één grote taak die alles doet. Dat scheelt dan ook weer in de executie tijd van het script en je kunt wat makkelijker bepalen wanneer welke taak uitgevoerd.

Andere optie is om een subset van data naar een wat meer geoptimaliseerde zoek database te zetten als Elastic of Solr. Zeker als je beetje goed kijkt naar wat je verwacht en daar een op maat bedacht schema voor kan verzinnen.

[Matis]

Wat ik zou doen is bij iedere wijziging of toevoeging van een boot, controleren bij welke gebruikers deze voldoet aan hun zoek criteria, dan sla je die match op in een tijdelijke tabel. Aan het einde van de dag stuur je alleen naar de unieke gebruikers hun match.

Mocht een gebruiker gedurende de dag zijn zoekcriteria aanpassen, dan zul je voor die gebruiker een nieuwe query moeten draaien over alle boten.

Daarnaast ben ik het met bovenstaande eens. Probeer het probleem op te knippen in losse stappen, desnoods in batch-vorm.

[Voutloos]

Bovenstaande klinkt wel redelijk. Ipv alles controleren tijdens wijzigingen aan het zoekprofiel kan je ook enkel tijdens de mailrun controleren of de matches voldoen. Dat is een stuk eenvoudiger, en heeft enkel invloed op oudere data. Sterker nog, misschien is de hele correctie/controle overbodig; een hoop werk voor een paar incidentele hits, en na gemiddeld 12 uur is altijd alles wel volgens je profiel. 😊

[TRON]

Het helpt als je zou kunnen aangeven hoe het nu werkt. Zou je dat kunnen beschrijven in verhaalvorm / pseudocode? Dan kunnen we je veel beter van advies voorzien.

[Hydra]

Bizar al die mensen die meteen antwoord geven zonder de TS te vragen waar nu de bottleneck zit. Da's een van de slechts eigenschappen die je kunt hebben als dev.

[kwaakvaak_v2]

Hydra schreef op woensdag 12 juni 2019 @ 13:34:
Bizar al die mensen die meteen antwoord geven zonder de TS te vragen waar nu de bottleneck zit. Da's een van de slechts eigenschappen die je kunt hebben als dev.

Niet goed lezen is ook niet de beste eigenschap voor een dev

Dutch_guy schreef op vrijdag 7 juni 2019 @ 15:50:
.....

Het script werkt, maar het loopt regelmatig vast. Er gebeurt ook van alles, de matching, mailen van de resultaten, wegschrijven van regels naar een XML bestand en daarnaast ook nog eventuele prijswijzigingen van boten binnen het zoekprofiel.

......

Zonder iets over de structuur of code te weten, is het runnen van meerdere taken binnen 1 job zelden tot nooit de meest ideale situatie. Vandaar ook het voorstel omdat eerst uit elkaar te halen en zodat je veel gerichter de taken periodiek kan laten draaien.

[Hydra]

kwaakvaak_v2 schreef op woensdag 12 juni 2019 @ 19:28:
Niet goed lezen is ook niet de beste eigenschap voor een dev

Die heb ik gezien. Die reactie (waar overigens nog weinig info in staat) kwam ruim na de reacties waar ik het over heb.

[Gomez12]

Op zijn simpelst gezegd : Herschrijf het megalomane script wat 1x per dag draait naar meerdere kleine scripts / acties die vaker draaien...

Alhoewel ik op dit moment totaal niet zie waar de bottleneck zit, in wezen lijkt het mij per zoekcriteria 1 zoekactie en dan de resultaten parsen en mailen...
Oftewel de zwaarste actie lijkt me je zoekactie en die zou geoptimaliseerd moeten zijn want die gebruik je op je website ook neem ik aan...

Als ik zou moeten gokken dan zou ik gokken dat je simpelweg tegen een asp.net request timeout aanloopt en in dat geval zou ik zeggen : Kijk eens naar iets als hangtime of gewoon een separaat proces wat buiten je website draait wat dit gewoon regelt vanuit de database dan heb je geen timeouts etc.

Maar ok, stel even dat je een giga-database hebt en een giga-aantal klanten met zoekquery's...
Dan zou ik zeggen :
Houd de id van de laatst doorzochte ad bij.
Dan in een separaat parallel process alle ads van na de id ophalen en vergelijken met de zoekcriteria, indien match dan ad-id +zoekcriteria-id opslaan in separate tabel.
(Of omgekeerd alle zoekcriteria ophalen en die doorvoeren voor alle ads na je laatste id)

Dan 1x per dag of wanneer je maar wilt, de zoekcriteria-id + ad-id ophalen (en checken of de ad nog geldig is) dan emails genereren en die emails weer op een message bus of pub-sub of weet ik veel wat voor mechanisme gooien waar je losse emailer het weer vanaf kan trekken.
Gooi er dan een server of 5 tegenaan om alle losse acties te doen et voila, je kan met heel entry's en heel veel zoekcriteria uit de voeten...

[Puch-Maxi]

Dutch_guy schreef op donderdag 6 juni 2019 @ 16:03:
Hoe kan ik dit efficiënter aanpakken? Hoe doet een partij als Marktplaats dit bijvoorbeeld met de zoekopdrachten die je kan opslaan en die dan naar je gemaild worden.

Hoe MP dat aan de serverkant doet weet ik niet, wel viel het mij op dat je een URL krijgt met daarin een je zoekquery inclusief een timestamp. Bijvoorbeeld:

https://www.marktplaats.nl/q/zundapp/?utm_content=button&&utm_campaign=SavedSearches#offeredSince:1560269113000|searchInTitleAndDescription:true|asSavedSearch:true

Als je de Unix timestamp 1560269113000 wijzigt dan krijg je oudere of nieuwere resultaten. Ze houden dus je query bij en de timestamp, als er nieuwe resultaten zijn krijg je een mail. Waarschijnlijk aggregeren ze de queries, zodat ze die maar een keer uit hoeven te voeren voor alle users met dezelfde query.

De key hier is dat MP geen resultaten verstuurt via de mail, maar een URL naar de zoekquery incl. timestamp .

[Dutch_guy]

Het gehele script is nu vernieuwd en efficiënter qua query's etc.

Ik sla nu inderdaad alle resultaten eerst op in een tijdelijke database, daarna mailt een apart script alle gebruikers met het zoekresultaat. Wie wat heeft ontvangen wordt nu ook direct in de database weggeschreven, voorheen moest dat noodgedwongen via een XML bestand.

Het matchen van een boot met zoekcriteria van gebruikers is nu binnen enkele seconden gedaan voor duizenden zoekenden.