latere toevoeging: De bijdrage van Andre Rijkeboer van 26 jan 11:40 geeft een verklaring voor de 'dubbele' jobs die meerdere keren verwerkt worden !!

Ik heb een vraag over de manier waarop publicaties verwerkt worden, met name hoe efficiënt dit gaat.

Bij het uploaden van mijn GEDCOM zie ik daarna bij het "Overzicht publicatieverwerking" dat mijn publicatie vrijwel direct vanuit de wachtrij verwerkt wordt. Ik verbaas me daar een beetje over omdat er nog 12 anderen in de wachtrij staan te wachten, sommige staan er al meer dan 24 uur. Kennelijk heb ik (gelukkig) voorrang.

Waar ik me nog meer over verbaas is dat er publicatie zijn die meermalen in de wachtrij staan, soms met een hele korte tussentijd, zie screenshots hieronder. Ik heb dit al veel vaker gezien en vraag me toch af of dit niet beter kan.

Ik zie 3 maal "Genealogie Meeldijk", 153.261 personen en 4 maal "Stamboom de Vries - Buddingh", 22.677 personen.

Dat wil toch zeggen dat alleen de laatste upload effectief is, want die overschrijft gewoon de vorige versies, terwijl die wel allemaal gewoon verwerkingstijd en processor capaciteit vragen, met name de grotere publicaties zoals hierboven.

Is het niet efficiënter om bij het uploaden eerst te kijken of de betreffende publicatie al in de wachtrij staat en die er dan uit te halen en als er al één verwerkt wordt, die verwerking af te breken, voordat de nieuwe upload in de wachtrij gezet wordt ?

P.S. Nadat ik dit stukje ingetikt had, keek ik nog eens naar het "Overzicht publicatieverwerking" en zie nu tot mijn verbazing 7 (zeven) maal de publicatie "Genealogie van Tinteren" in de wachtrij. De kortste tussentijd is 35 seconden! Dit screenshot toch nog maar even extra toegevoegd hieronder.

Samenvatting:

1. Het is onduidelijk op basis waarvan 'n bestand in de wachtrij aan de beurt is om verwerkt te worden.
2. Bestanden staan vaak meer dan 1x in de wachtrij. Je stelt 'n check voor: indien hetzelfde bestand al in de wachtrij staat of al verwerkt wordt wordt dat bestand verwijderd resp. verwerking afgebroken, omdat er immers 'n nieuwere versie is. Goed plan! 

Over hetzelfde onderwerp: Waarom duurt het verwerken van 10 wijzigingen in openbaarheid van personen 1u 25m 3s bij 'n bestand van 67.113 personen zonder afbeeldingen? Dat duurt langer dan het verwerken van 'n nieuwe GEDCOM?! 

Kan de link naar Overzicht Publicatieverwerking a.j.b. ook getoond worden na klikken op Publicatie Bijwerken?

De strategie voor verwerking lijkt niet optimaal te werken. Mijn voorstel zou zijn:

1. Bij meervoudig aanbieden van dezelfde publicatie altijd oudere versies uit de rij verwijderen.
2. Verwerking uitvoeren in volgorde van grootte (dus de kleinste eerst, die zijn snel klaar), zodat er geen lange rij kan ontstaan.

N.b.:
Vooral stambomen met veel afbeeldingen duren lang; sommige stambomen bevatten tienduizenden afbeeldingen, die bij nadere beschouwing voortdurend kopieën blijken te zijn van dezelfde afbeelding. Dit is niet bevorderlijk voor de snelheid en levert ook voor de publicatie geen enkele toegevoegde waarde. Zou dit wellicht als fout kunnen worden teruggemeld aan de gebruiker?

punt 1 is precies wat ik voorgesteld heb. Ik zou dan ook nog een 'oudere' job die al in uitvoering is afbreken als dat mogelijk is.

punt 2 is denk ik al ongeveer geïmplementeerd, want ik had het idee dat ik voorrang kreeg met mijn job van 4.500 personen. Bij de volgende verversing moest ik een paar uur wachten omdat er al een grote job bezig was. Ik zag toen ook dat andere jobs voorgingen. Dat waren nog kleinere jobs dan die van mij.

Verder zou ik wel onderzocht willen hebben hoe het kan dat in mijn laatste screendump hierboven de job "van Tinteren" 7 keer achter elkaar in de wachtrij staat, waarvan 5 keer binnen 5 minuten. Als dat terug te voeren is op de manier van werken van de GO gebruikers, wordt punt 1 hierboven extra belangrijk om in te voeren. Als je een upload gedaan hebt, wacht je toch op het resultaat voordat je weer een upload doet, lijkt mij.

"Als je een upload gedaan hebt, wacht je toch op het resultaat voordat je weer een upload doet, lijkt mij."

Welnee, zodra je in de gaten hebt dat je iets stoms gedaan hebt, of nog 'n genant foutje ziet en 'n nieuwe GEDCOM genereren met 1 klik te doen is gaan nogal wat gebruikers waarschijnlijk meteen 'n nieuwe GEDCOM uploaden. Wat mezelf nogal 'ns overkomt is dat ik vergeet om 'n paar mensen in losse eilandjes uit te sluiten van publicatie. Die losse eilandjes zorgen ervoor dat de publicatie niet 1 cluster is terwijl dat wel de bedoeling is voor 'n bepaalde publicatie. Tijdens 't uploaden schiet me zoiets dan te binnen:-) In ProGen is het genereren van 'n GEDCOM relatief veel werk doordat je per keer aan moet geven welke velden wel/niet gepubliceerd mogen worden. Ik publiceer zo min mogelijk velden.  Dus dat ontmoedigt nogal om m'n publicatie te verversen.

Vandaag staat deze gigantische klus zelfs 4x gelijk in het onderhanden werk:

De 2 jobs van 24 dec met een tussentijd van 10 seconden.!!

Dit lijken mij echter 2 verschillende publicaties, gezien de 2 achteraan de titel.

In theorie lijkt het mij op deze manier zelfs mogelijk dat van eenzelfde publicatie de 'nieuwste' job die als laatste geupload is als eerste klaar is en dus later wordt overschreven door de 'oudste' job.

Toegevoegd:

Nog een reden te meer om te voorkomen dat 2 jobs voor dezelde publicatie tegelijk verwerkt kunnen worden.

@GerritScholl

Beide met exact hetzelfde personen en exact hetzelfde aantal afbeeldingen?

@Jan: Inderdaad, ik zou ook wel eens willen weten waarom er 2 vrijwel identieke publicaties zijn, die ook nog eens veel verwerkingscapaciteit vergen. Bovendien worden ze steeds per 2 vlak achter elkaar gestart. Ik heb tussendoor een heel stel screendumps gemaakt en daaruit blijkt het volgende.

Van de 4 jobs die jij aangaf in je bijdrage van 25 dec 09:22 waren er 2 van 24 dec 21:47 en 2 van 25 dec net voor 09:00. In de lijst van verwerkte jobs vind ik nu (26 dec 17:15) van dezelfde publicaties:

• 2023-12-26 14:27:42 » Stamboom Jager en Dijkstra - 38.801 personen, 2.355 afbeeldingen - verwerkt in 1u 25m 8s
• 2023-12-26 13:31:22 » Stamboom Jager en Dijkstra 2 - 38.801 personen, 2.355 afbeeldingen - verwerkt in 29m
•  
• 2023-12-24 20:38:40 » Stamboom Jager en Dijkstra - 38.801 personen, 2.355 afbeeldingen - verwerkt in 3u 17m 2s
• 2023-12-24 19:39:37 » Stamboom Jager en Dijkstra 2 - 38.801 personen, 2.355 afbeeldingen - verwerkt in 2u 18m

Merkwaardig genoeg zie ik daarbij geen job die op 25 dec gereed gekomen is. Maar uit de screendump hieronder blijkt dat de 2 jobs met upload van 24 dec 21:47 op 25 dec om 18:49 nog actief waren. Die van 26 dec hierboven zijn waarschijnlijk later nog weer gestart. Aan het grote verschil in verwerkingstijd kun je zien dat een later ge-uploadde job toch als eerste klaar kan zijn.

Hieronder in Screenshot_20231225-184915_Chrome.jpg, gemaakt op 25 dec om 18:49. Je ziet dat de 2 jobs van 24 dec 21:47 toen nog actief waren. Misschien zijn ze vastgelopen en afgebroken. Als ze hierboven toch staan als gereed gekomen op 26 dec, klopt er niets van de verwerkingstijd. De jobs van 25 dec net voor 09:00 staan er niet meer bij, dus zijn ze klaar, maar ze staan niet in de lijst van verwerkte publicaties. Rara hoe kan dat.

Merkwaardig genoeg zie ik daarbij geen job die op 25 dec gereed gekomen is.

Ik had meerdere screenshots gemaakt met mijn telefoon. Die had ik nog niet allemaal bekeken. Daarop is wel te zien dat er een Job "Stamboom Jager en Dijkstra 2" gereed gekomen is op 25 dec 00:08:59. Die is nu niet meer te zien, geschrapt uit de lijst?? De screenshots zijn genomen resp. op 25 dec 11:48 (rechts) en op 27 dec 17:48 (links). Dezelfde jobs zijn rechts en links te zien, behalve de job "Stamboom Jager en Dijkstra 2" die links is verdwenen. Als er op deze manier in de lijst geschrapt wordt is het nauwelijks mogelijk dit soort dingen nog goed te analyseren.

Deze job was weliswaar eerder gestart, maar het toont aan dat de lijst dus niet te vertrouwen is en dat er meer jobs kunnen ontbreken.

Misschien is het ook relevant de aard van het bijwerken van 'n publicatie erbij te betrekken; nieuwe GEDCOM uploaden, extra afbeeldingen ge-upload of wijzigingen in scherm openbaarheid personen verwerken.

Bij mijn experimenten met het uploaden van afbeeldingen heb ik ontdekt dat, indien ik via Dropbox mijn afbeeldingen upload, er meerdere verwerkingsjobs worden aangemaakt met een paar seconden verschil, terwijl het uploaden via "upload afbeeldingen" het maar één verwerkingsjob oplevert. Het verwijderen van dubbele verwerkingsjobs kan dus voor problemen zorgen omdat de inhoud niet hetzelfde is. Ik denk dat er naar het triggermechanisme van het genereren van een verwerkingsjob uit de Dropbox gekeken moet worden. Er moet waarschijnlijk gewacht worden tot bijvoorbeeld er een minuut geen items meer in de Dropbox bijgeplaatst zijn. 

Ik heb een plus abonnement en vermoed dat ik daarom voorrang krijg op publicaties die geen (plus)abonnement hebben.

Wat me wel opvalt is het que principe van de wachtrij van "Last In First Out". Dit zou moeten veranderen naar het que principe van "First In First Out".

@Andre.

Dit is een zeer waardevolle bijdrage, dank Andre. Hier kan Bob t.z.t. wel wat conclusies uit trekken, denk ik. Ik zal het startbericht van dit item aanpassen om naar deze bijdrage te verwijzen.

Nogmaals dank.

Je schreef ook":

Wat me wel opvalt is het que principe van de wachtrij van "Last In First Out". Dit zou moeten veranderen naar het que principe van "First In First Out".

Ik denk dat het nu niet "Last In First Out" is. Er wordt al rekening gehouden met speciale gevallen, hoe precies is mij ook niet duidelijk, maar als je bovenaan in de wachtrij staat wil dat niet zeggen dat je als eerstvolgende aan de beurt komt. Ik heb gezien dat andere die daaronder staan toch eerder verwerkt worden en ook dat ikzelf ineens onverwacht aan de beurt was. Ook dat een job die ik helemaal niet gezien had in de wachtrij, plotseling al verwerkt werd.

Interessant, inmiddels geprobeer e.e.a. te reproduceren, 3 afbeeldingen met korte tussenpozen ge-upload via Dropbox. Dat levert 3 jobs rond 12:25 uur:

En om 12:29 zijn 2 van m'n jobs verdwenen?! en is 1 job verplaatst naar de categorie "Publicaties die nu worden verwerkt". Zouden ze automatisch samengevoegd zijn? 

Bij publicatie Genealogische gegevens uit Noord-Oost Overijssel hoort 'n betaald abonnement. Die publicatie wacht nog steeds op verwerking, terwijl ik 'n Probeer-abonnement heb. Dus, ik vermoed dat het vermoeden van Andre niet klopt, op basis van wat ik zie. Andre schreef: "Ik heb een plus abonnement en vermoed dat ik daarom voorrang krijg op publicaties die geen (plus)abonnement hebben."

De 3 bestanden die ik heb ge-upload via Dropbox zijn wel zichtbaar in het afbeeldingenbeheerscherm, ze staan dus wel op de GO-server, ik kan ze daar alleen verwijderen omdat ze niet gekoppeld zijn aan personen. De publicatiedatum zal niet veranderen door deze Dropbox-actie, er is in de publicatie immers niets veranderd.

@Pauline,

Als jij het niet kunt reproduceren, wil dat nog niet zeggen dat het probleem er niet is. Andre geeft duidelijk aan dat hij zijn publicatie meerdere keren in de lijst heeft zien staan, terwijl het toch zijn bedoeling was dat maar één keer te doen. Mogelijk spelen zeer tijd kritische elementen daarbij een rol en daardoor b.v. ook de drukte op de GO servers, op het internet en op de lokale PC.

Verder heb ik in mijn bijdrage van 21 dec 21:57 al aangetoond dat er geschrapt wordt in de lijst van publicaties die al lang daarvoor verwerkt zijn en jij ziet daar ook allerlei rare verschijnselen. Kortom, GO gaat ook niet goed om met het presenteren van de gegevens in die lijst.

Ik denk dat Bob genoeg aanknopingspunten heeft om dit probleem te tackelen. Tijd daarvoor vrijmaken zal zijn grootste probleem nu zijn denk ik.

Wat betreft de vraag wie als eerste aan de beurt is weet ik niet of er ergens in de FAQ of zo een beschrijving van de huidige GO policy is. Ik heb daarover geen klachten omdat ik geen documenten, etc. upload en het niet erg vind als ik eens een uurtje moet wachten.

Dag Gerrit, ik geloof niet dat ik ergens beweerd heb dat het probleem van Andre niet bestaat omdat ik het niet kon reproduceren:-) Verder eens met de urgentie van dit probleem zoals jij die schetst.

Mijn interpretatie van genoemde verschijnselen: Een publicatie kan meerdere malen in de wachtrij voorkomen als het gaat om verschillende wijzigingen in het profiel, dus bijvoorbeeld 1, het uploaden van een nieuwe Gedcom-file, 2, het aanpassen van de introductie-pagina,  3, het toevoegen van afbeeldingen,  4, het plaatsen van een verhaal.  Alle wijzigingen worden als aparte mutaties behandeld.

Waarom het aanpassen van slechts enkele namen soms heel lang duurt: als er bijvoorbeeld startpunten met stamvaders in de publicatie voorkomen, dan moeten de nieuw gepubliceerde personen in de overzichten worden geplaatst. Nieuwe overzichten moeten worden gemaakt (PDF's, HTML, etc)

Het is inderdaad niet heel efficient, vooral omdat voor elke wijziging opnieuw het hele Gedcom bestand moet worden geplaatst, ook als die in de meeste gevallen minstens 99% gelijk is aan het oude bestand. Inclusief het opnieuw aanmaken van overzichten etc.  Maar zo is het nou eenmaal binnen de huidige software.  Een Gedcom is niet deelbaar, de nieuwe versie vervangt de oudere volledig.  Het zou mooi zijn als er een gesynchroniseerd genealogisch netwerk zou zijn, waarvan alleen de aanpassingen doorgegeven hoeven te worden, en die dan ook direct gedeeld zouden worden met iedereen die deze personen in zijn bestand heeft staan.

@sander.

Ik denk dat het zo niet werkt. Ik denk dat bij iedere upload van een GedCom, de hele GO publicatie vrijwel van scratch helemaal opnieuw in één verwerkingsjob opgebouwd wordt.

Bob kan hier misschien t.z.t. wat meer over zeggen.