performance problemen

[mattijsstam]

• [ ] cachen
• [ ] limieteren van interactieve elementen

[thesethtruth]

Braindump met @TAVMWB

1. Beperkte oplossingsruimte garanderen

   Stel 4 casussen, iedere run op 1 minuut. 14 cores beschikbaar voor runs (AL). Stel je neemt 14 uur (de nacht tussen twee werkdagen) dan heb je 3.5 uur per casus en kan je grofweg 1.7k parameters nemen. Doe je er maar twee per nacht dan heb je het dubbele aantal parameters beschikbaar (3.4k), wat representatief is voor 5 sliders in stapjes van 5 verdeeld.

Stel 1 casus per nacht, 11.7k mogelijke runs dan krijg je 1 slider van 5 opties erbij.

Dit schaalt dus niet heel lekker. Mogelijk moeten we dan een trucje doen om de dimensionality te doorbreken zoals PCE of uberhaupt surrogate modelling.

Dedicated server (engine.holontool) upscalen naar de AMD Ryzen™ 9 7950X3D, 20% hogere threadscore.

3. Scenario runner

   1. Moet aangeven welke cache invalide is en waarom
   2. Manual job (niet scheduled en niet event based)
   3. Oplossingsruimte opbouwen op basis van aangemaakte pagina's (storyline en challenge)
   4. Indicatie geven van de tijdsduur voor het doorrekenen van de gevonden oplossingsruimte
   5. Daadwerkelijk de batch afwerken (overdag processen vrij laten voor andere taken)

4. Cache (vrij basic) memoization

   1. Django model met de scenario inpute data en de scenario resultaat data
   2. De Django view neemt de cache mee en gebruikt de hash van de inputs mee om te bepalen wat de laatste versie was.
   3. Cache opsplitsen naar post-AL, post-ETM, to-user (code aanpassingen).

5. Cache invalidatie

   1. Inzichtelijk maken van welke scenarios invalide zijn
   2. Inzichtelijk maken van waar de verandering zit
   3. Aftrappen van runner vanuit beschermde pagina

6. Logging

   1. Afgetrapt door wie
   2. Hoe ver ben ik
   3. Hoe lang moet ik nog
   4. Hoeveel processen draaien er nu op de cloud
   5. Foutmeldingen mailen?

[TAVMWB]

Aanvulling op (5.) ipv een scenario hashen op de interactieve elementen en hun waardes, kunnen we ook altijd de interactieve elementen toepassen op het geclonede scenario, en dan de cache indexen op een hash van de scenario json die anylogic ingaat. Het nadeel hier van is dat je de rekentijd van de interactieve elementen toepassen altijd krijgt, maar het voordeel is dat het indexeren en opzoeken van cache records simpeler wordt.

EDIT: minder makkelijk dan het lijkt, omdat door het clonen van scenarios de id's constant veranderen

[TAVMWB]

Verder kan het aantal combinaties van configuraties verminderd worden als we het alleen genereren op een per-sectie basis ipv op een pagina niveau

[TAVMWB]

Tasks:

• [x] Sliders discretiseren
  • [x] toevoegen aan backend model
  • [x] toevoegen aan frontend
• [x] Hash functie maken voor endpoint input
  • [x] Serializer/hashing functie maken voor interactieve elementen inhoud
  • [x] ETM/Anylogic/Postprocessing version achterhalen
  • [x] Functie maken die alles samenstopt in een sha256 hash, prepended met scenario id
• [x] Cache implementeren in endpoint
  • [x] Ignore cache optie in url parameters
• [x] Runner script die alle scenario combinaties afgaat
  • [x] Endpoint aan kunnen roepen vanuit Django script
  • [x] Configuratie combinaties uit kunnen rekenen
    • [x] Interactieve elementen voor een scenario ophalen
    • [ ] Secties meenemen
• [x] Logging
• [ ] Tests
  • [ ] Endpoint aanroepen vanuit cache runner
  • [ ] Cache runner combinaties
  • [ ] Endpoint caching
  • [ ] Regression tests met pytest
• [x] Documentatie
• [ ] Pizza eten 🍕

Cache example: https://testdriven.io/blog/django-low-level-cache/

[TAVMWB]

For slider discretization: Given a number of steps in the slider, calculate interval size. Special case: if nothing is filled in or 0, ignore interval altogether (go for continuous range)

[pascalalferink]

Frontend is completed:

• Field discretizationSteps is added to the slider (see screenshot below of wagtail)
• Steps are also being used in the frontend
• The values of the slider are being floored (66,7 becomes 66)

Because input type range can't handle fractions such as 1/3, I needed to refactor the ImageSlider a bit: It keeps track of two values:

1. an actual value, this is being used in the calculations
2. A slider value: If discretizationSteps has a value, the slider has these amount of steps. If you use the settings below (config 1), the user sees a slider from 10 until 80 with the following steps (10-20-30-40-50-60-70-80). If the user uses the values from config 2, the user sees a slider from 0 until 100 with the steps (0 -33-66-100)

Pleas keep in mind: if you use a config with steps, make sure the defaultvalue is one the values is the steps, otherwise, the result looks like the screenshot below (used with config 2, with default value 50)

Config 1

Config 2