Project

General

Profile

Bug #4175

Oprettelse af karruseller er til tider ekstremt langsom

Added by Stefan Søndervang 3 months ago. Updated 23 days ago.

Status:
Closed
Priority:
Urgent
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Inspiration - Karruseller

Description

Problem 1

Jeg har på Rudersdal staging oprettet 25 forsidekarruselsøgninger (det i den røde kasse på billedet) fordelt på flere forsidekarruselpaneller (det i den grønne kasse på billedet) på forskellige sektioner og forsiden. 

Jo flere karruseller jeg har oprettet, jo sværere har det været at oprette karruseller. Lige nu er jeg kommet op på 25, og når jeg forsøger at oprette en mere, så vil den ikke afslutte. Den bliver bare på redigeringssiden (se billede herunder). Jeg eksperimenterede med om det var kompleksiteten eller antal hits i søgninger, som påvirkede om den ville oprette karrusellen. Intet at konkludere. Jeg tjekkede på upgrade om jeg kunne oprette de karruseller, som jeg ikke kunne på vores staging, og det kunne jeg godt. Der var svingende svartider på opensearch, som kunne have påvirket det, men jeg kunne godt oprette samme karruseller i samme periode på upgrade.

Jeg har efterfølgende slettet karruseller og kan igen oprette karruseller.

Problem 2

Det skifter enormt meget om man kan gemme en søgning. Det er som om at kompleksiteten af en søgning eller mængden af hits påvirker om man kan gemme en karrusel.

Skal undersøges

  1. Hvorfor påvirker antallet af karruselsøgninger at man kan oprette flere?
  2. Påvirker kompleksiteten i en søgning at man kan oprette en karrusel?
    • Fx "uu=nt and facet.literaryForm=skøn* and term.type=(bog not *stor* not net* not ebog not billedbog) not term.subject=krimi and holdingsitem.accessionDate>="NOW-14DAYS" and facet.category=voksenmaterialer"
  3. Påvirker antal hits i søgningen at man kan oprette en karrusel?
    • Fx "*"
  4. Påvirker lang svartid på opensearch oprettelse af karruseller?
  5. Hvad er konsekvenserne af rigtig mange karruseller for hjemmesiderne fx ift performance?

 

Skal laves

Man skal kunne oprette så mange karruseller, som man vil uden at det påvirker noget.

Hvis kompleksiteten af en søgning eller mængden af hits forhindrer karrusellen at blive gemt, så skal systemet ikke tage stilling til kompleksiteten. 

Skærmbillede 2019-04-02 kl. 10.20.18.png (46.8 KB) Skærmbillede 2019-04-02 kl. 10.20.18.png b1) jeg kan slet ikke få lov at se forsiden endsige da at redigere den Gitte Barlach, 04/02/2019 11:07 AM
Skærmbillede 2019-04-02 kl. 10.27.23.png (26.6 KB) Skærmbillede 2019-04-02 kl. 10.27.23.png b3) systemet siger forsiden er låst - men ingen af de andre testere er inde og redigere Gitte Barlach, 04/02/2019 11:10 AM
Skærmbillede 2019-04-02 kl. 10.33.39.png (1.26 MB) Skærmbillede 2019-04-02 kl. 10.33.39.png b3) systemet siger forsiden er låst -og den låser sig ikke op igen, selvom jeg venter Gitte Barlach, 04/02/2019 11:11 AM
Skærmbillede 2019-04-02 kl. 10.46.14.png (531 KB) Skærmbillede 2019-04-02 kl. 10.46.14.png b3) systemet siger forsiden er låst -og den låser sig ikke op igen, selvom jeg venter; ventetiden bliver bare længere og længere Gitte Barlach, 04/02/2019 11:12 AM

Related issues

Related to DDB CMS - Bug #4295: Deaktivér ratings på karuseller og søgeresultatsiden SKAL IKKE MERGESReviewed
Related to DDB CMS - Bug #4296: Lazy load (AJAX) ratings for forbedret performanceResolved (tag version)

History

#1 Updated by Stefan Søndervang about 2 months ago

  • Subject changed from Oprettelse af ca 20+ forsidekarruseller gør at vil den ikke gemme flere karruseller to Oprettelse af karruseller er til tider ekstrem langsom
  • Description updated (diff)

#2 Updated by Stefan Søndervang about 2 months ago

  • Description updated (diff)

#3 Updated by Stefan Søndervang about 2 months ago

  • Priority changed from Normal to Urgent
  • Target version set to Release 31 - bugfixes

#4 Updated by Stefan Søndervang about 2 months ago

Jeg ved ikke om det er problemerne i sagerne #4194 og #4139, der påvirker dette. Vi skal nok vente og se om de rettelser fikser problemet.

#5 Updated by Gitte Barlach about 2 months ago

Jeg har testet på upgrade-fbs med rel. 30-1 (4.7.0-rc2) der bl.a. indeholder #4194 og #4139

Udgangspunktet for min test var at der ikke var nogen forsidekarruseller overhovedet

a) jeg opretter 1 forsidekarrusel med 4 faneblade:

Faneblad 1: "Læsernes bogpris 2019"
Søgestreng: 55136041 or 54975171 or 54996039 or 54078714 or 54019181 or 55113092 or 54884230 or 54203608 or 54872038 or 54700180

Faneblad 2:"Sjove bøger for de mindste"
Søgestreng: 27580750 OR 53618863 OR 52111188 OR 55100659 OR 52527899 OR 55143331 OR 51728394 OR 55103216 OR 45973115 OR 52386950 OR 54260180 OR 54956908 

Faneblad 3: "Konfirmation"
Søgestreng: 29051992 OR 52301394 OR 52732867 OR 52482089 OR 25932056 OR 25730259 OR 51869184 OR 52232902 OR 52776090 OR 51578058 OR 24268179 OR 52045738 OR 52664284 OR 26646669 OR 50961095 OR 24612090 OR 27997619 

Faneblad 4: "Hej skole - farvel børnehave"
Søgestreng: 54158971 or 29924708 or 52459974 or 53775926 or 52310121 or 53237517 or 53852521 or 46189159 or 28653336 or 46196945 or 29682038 or 50967492 or 52200695 or 52261732 or 50564509 or 53316298 or 51443195 or 51580974 or 52436044 or 29991413

a1) det er langsomt at arbejde i backend. 
5-6 sekunder tager det at gemme min forsidekarrusel, og 15-16 sekunder (!) før forsiden er gemt. 

b) jeg opetter nu 1 ny forsidekarrusel, dvs. indsætter et nyt panel og lave 1 karrusel med 1 faneblad. 
Fane 1: "Påske"
Søgestreng: 51545354 OR 29179824 OR 28203551 OR 24484246 OR 24492206
Jeg gemmer karrusellen og gemmer forsiden. Det er meget langsomt igen. Hvad værre er: 
upgrade går efterfølgende i selvsving: 
b1) da jeg efterfølgende prøver at gå ind igen og redigere, tager 30 sekunder før jeg bliver logget ind, og jeg kommer ikke ind på forsiden, men bliver smidt hen på en materialevisnig (et af de materialer, der indgår i karrusellen); jeg prøver at gå til forsiden, men det kan jeg slet ikke få lov til. 
b2) Jeg logger derfor ud. Det tager 43 sekunder (!) før jeg var logget ud og forsiden var indlæst
b3) jeg logger ind igen. NU siger systemet pludeselig at der er en anden der er ved at redigere forsiden, så det er låst, og jeg skal vente 7 mins før det låses op. Med mindre jeg klikker på OK. Jeg vælger at prøve at vente til systemet låser sig selv op,; jeg logger derfor ud. Da jeg efter 7 min logger ind igen er systemet stadig låst, men nu skal jeg vente 13 min. før det låses op. 
Ved næste forsøg siger den jeg skal vente 26 min før den låses op. Derfor vælger jeg manuelt at låse den op, hvilket jeg godt kan.  

 

#6 Updated by Tue Gaston about 2 months ago

  • Subject changed from Oprettelse af karruseller er til tider ekstrem langsom to Oprettelse af karruseller er til tider ekstremt langsom

#7 Updated by Gitte Barlach about 2 months ago

Da DBC havde performance problemer i det tidsrum min test foregik på, gentester jeg hermed.
Udgangspunktet er det samme, dvs. upgrade-fbs med 4.7.0-r 2 og ingen karruseller til en start. 

1) jeg opretter 1 karrusel med 4 faneblade:

Læs højt sammen - for de større børn: 28448589 or 52951151 or 53071619 or 29106312 or 52557224 or 52655757 or 51807839 or 51214722 or 46158822 
Læs højt sammen - for de mindre børn: 53654037 or 50653595 or 51923367 or 52855888 or 52855888 or 53337511 or 52389003 or 53619762 or 29153884 or 25707036 or 52389003
Vi vil have spænding: 51387619 or 51724143 or 29804281 or 28307454 or 22441361 or 26177251 or 27578276 or 23165236
Vi vil udfordres: 29020248 or 22669524 or 27026273 or 26562058 or 20762691 or 46197054 or 50933733 or 53226515

Det er 17 sekunder at gemme karrusellen. Og 8,28 sek. at gemme forsiden. 
 

2) jeg opretter nu en ny karrusel med 1 faneblad:
Det tager 11 sekunder at genne karrusellen og 9,50 sek. at gemme forsiden. 

Så umiddelbart er svartiderne på denne type få basale karruseller hvor søgestrengen består af faustnummer or faustnumer or faustnummer uden yderligere filtreringer okay, selvom det tager længere tid at gemme dem, end før i tiden. 

#8 Updated by Gitte Barlach about 1 month ago

Gentestet denne på upgrade-fbs med 4.7.0-rc3:

Jeg laver en karrusel med 3 faneblade med søgninger á la faustnummer OR faustnummer OR faustnummer; det går okay, selvom den gennemsnitlige tid for at oprette og gemme ikke er imponerede. 

Da jeg nu vil oprette endnu et faneblad i samme karrusel, denne gang med en CQL søgning, lader det sig ikke gøre. Søgningen på det der skulle have været faneblad 5 er: ma=bå and em=(kogebøger or madopskrifter). Jeg klikker på  knappen "finish" og venter. Der sker intet. Efter 2149 sekunders ventetid (sic!) giver jeg op. Samme søgning vis det alm. søgefelt på upgrade-fbs giver et resultat, og dette resultat caches tydeligivs. Så søgningen kan altså afvikles. 

Jeg opretter nu en NY karrusel på upgrade-fbs. Med 1 faneblad, og jeg indsætter den helt samme søgning, nemlig ma=bå and em=(kogebøger or madopskrifter). Jeg klikker på Finish og denne gang kan jeg pludselig godt gemme karrusellen. Det tager kun 08,54 sekunder. 

Okay - det performer som vinden blæser. 
Lidt senere på dagen prøver jeg igen. Dels tilføjer jeg yderligere et par CQL-søgninger til min nye karrusel, og sætter endvidere rankering samt filtrering på at titlerne skal være hjemme. Det går okay, selvom backend´en hopper rundt og indlæses rykvis. 
Endvidere tilføjer jeg et faneblad og en ny søgning, nemlig uu=nt AND ts=blu-ray AND (kk=bkm201507 OR kk=bkm201508) til min første karrusel. Det går også godt. 

#9 Updated by Christel Krabbenhøft about 1 month ago

  • Assignee changed from Christel Krabbenhøft to Thomas Hansen

#10 Updated by Thomas Hansen 30 days ago

Altså, som udgangspunkt, hvis brønden eller forsideservicen raller, så kommer det til at gå langsomt, det er der ingen vej udenom (uden at være virkelig kreative).

Nå, men jeg har gravet lidt i det...

Der hvor det største hit rammer, det er når man trykker afslut når man har tastet nye karouseller ind. Submit handleren henter den første side af hver karousel for at der er noget i cachen når siden bliver reloaded. Men den bruger også cachen, så det er kun de tilføjede karouseller der trækker ned.

Med de 4 søgninger fra #5 og varme cacher har jeg submit og rendering omkring de 100 millisekunder. De lægger panels så lidt ekstra oveni, men det kan vi ikke nemt lige gøre så meget ved. På iskolde cacher tager det 8 sekunder, men sansynligheden for at der ikke er nogen der har været forbi nogen af materialerne (og fået dem i cachen) før bibliotekarern sætter dem i karousel, er lille.

Men mens jeg sad og timede det, bemærkede jeg at den periodisk var over 2 sekunder om at rendere. Efter en del graven for at finde synderen fandt jeg frem til at det var rating widget'en der trak det hele ned. Den laver nemlig en seperat request til openlist for hvert materiale, og har en cache levetid på 60 sekunder. Der skal ikke meget sløvhed fra openlists side til før det virkelig kan trække ned.

Det smarteste ville være hvis rating widget'en fungerede som covers og satte en placeholder ind hvis den ikke fandt noget i cachen, og så loadede ratings over AJAX (og så ville bulk forespørgelser være smart, men det er en anden snak). Men det er ikke bare lige et fem minutters fix.

 

#11 Updated by Rolf Madsen 25 days ago

  • Assignee changed from Thomas Hansen to Christel Krabbenhøft

@Christel

Ratings lader til at være et generelt problem for performance.

Jeg foreslår derfor at vi beder Thomas undersøge den mest hensigtsmæssige indførelse af AJAX'ificering af ratings, og at vi så får det løst.

 

Kan AJAX'ificering af ratings udføres en gang for alle ratings, tager det mindre tid for de efterfølgende visninger eller er det en lige stor opgave for alle ratings visninger?

Hvis

  1. Et fix for alle visninger -> lad os få det løst med det samme.
  2. Individuelle fix for hver visning -> Prioritér AJAX'ificering af karuseller og søgeresultatvisningen.
  3. Undersøg hvilke steder vi faktisk vil have ratings vist og fjern de visninger vi ikke længere ønsker.

#12 Updated by Gitte Barlach 24 days ago

  • Status changed from Needs analysis to Ready for development

implementerering af asynkron hentning af ratings fra OpenList anbefales også jvf. Kaspers arbejde og konklusioner i #4214

"Opgaven er oprindeligt baseret på en hypotese om at entitymodellen medførte et unødvendigt performanceoverhead. Resultatet fik mig til at overveje hvorfor det kunne være. Én forskel er at den oprindelige implementation endnu ikke dækkede visning af ratings fra OpenList. Data fra andre eksterne systemer der er i spil i forbindelse med søgeresultatvisningen (Covers og Availability) bliver hentet asynkront men så bliver data for ratings hentet synkront. Jeg har derfor også foretaget en måling hvor jeg fjerner ratingsvisningen fra det opdaterede resultat.

Fjernelse af ratings giver en forbedring af svartider på >40% (3.11s vs. 5.69s).

På den baggrund foreslår jeg at vi implementerer asynkron hentning af ratings fra OpenList. Dette kan foregå uafhængigt af en beslutning af om vi vil fortsætte med dette arbejde eller ej."

#13 Updated by Rolf Madsen 23 days ago

  • Related to Bug #4295: Deaktivér ratings på karuseller og søgeresultatsiden SKAL IKKE MERGES added

#14 Updated by Rolf Madsen 23 days ago

  • Related to Bug #4296: Lazy load (AJAX) ratings for forbedret performance added

#15 Updated by Rolf Madsen 23 days ago

  • Status changed from Ready for development to Closed

Jeg har oprettet:

  1. Deaktivér ratings på karuseller og søgeresultatsiden- https://platform.dandigbib.org/issues/4295
  2. Lazy load (AJAX) ratings for forbedret performance - https://platform.dandigbib.org/issues/4296

Dette issue lukkes hermed.

Also available in: Atom PDF