73 lines
4.6 KiB
Markdown
73 lines
4.6 KiB
Markdown
# Verwachte performance op lange termijn
|
|
|
|
## Status van deze verwachting
|
|
|
|
De onderstaande schaalinschatting is een architectuuranalyse, geen benchmark. Werkelijke grenzen hangen af van PostgreSQL, netwerkvertraging, documentgrootte, aantallen versies, browser en gelijktijdige gebruikers. Optimaliseer pas na meting met representatieve data.
|
|
|
|
## Verwacht schaalbeeld
|
|
|
|
| Omvang | Verwachting met huidige architectuur |
|
|
| --- | --- |
|
|
| Honderden pagina's, tientallen CMaps | Normale lees-, schrijf- en zoekacties horen ruim voldoende te zijn op een gewone lokale server. |
|
|
| Enkele duizenden pagina's, honderden CMaps | Paginaweergave en geïndexeerd paginazoeken blijven waarschijnlijk goed; CMap-zoeken, catalogusgrootte en verbindingsopbouw worden zichtbaar. |
|
|
| Tienduizenden pagina's of veel grote CMaps | Paginering, connectionpooling, geïndexeerd CMap-zoeken en versie-/bijlagebeleid worden waarschijnlijk noodzakelijk. |
|
|
|
|
Het ontwerp is dus passend voor een persoonlijke of teamwiki. Het is niet zonder aanvullende maatregelen ontworpen als internetbrede kennisbank met zeer veel gelijktijdige gebruikers.
|
|
|
|
## Sterke performance-eigenschappen
|
|
|
|
De actuele pagina staat direct in `pages`; voor normaal lezen hoeft geen versiegeschiedenis te worden opgebouwd. Titel en Markdown leveren een opgeslagen gewogen zoekvector met GIN-index. PostgreSQL verwerkt transacties en locking dicht bij de data. De browser ontvangt bij de paginacatalogus alleen metadata en haalt Markdown pas op bij gebruik.
|
|
|
|
Vendor-assets worden lokaal geserveerd en veranderen niet tijdens normaal gebruik.
|
|
|
|
## Belangrijkste toekomstige knelpunten
|
|
|
|
### CMap-zoeken
|
|
|
|
Paginazoeken gebruikt een opgeslagen index. CMap-zoeken bouwt per query tekst uit JSONB-items en maakt daar op dat moment een `tsvector` van. Bij veel of grote kaarten wordt dit een volledige scan. Voeg dan een opgeslagen zoektekst/`tsvector` en GIN-index aan `concept_maps` toe, bijgewerkt tijdens CMap-opslag.
|
|
|
|
### Databaseverbindingen
|
|
|
|
`call-with-wiki-database` opent en sluit voor iedere dienstaanroep een PostgreSQL-verbinding. Dit houdt lifecycle en foutisolatie eenvoudig, maar connection setup wordt bij hogere requestfrequentie overhead. Een begrensde connectionpool is dan logischer dan één globale verbinding. Meet eerst connecttijd, querytijd en gelijktijdigheid afzonderlijk.
|
|
|
|
### Catalogi
|
|
|
|
`list-pages` en `list-concept-maps` leveren alle huidige metadata. Dat is prettig voor client-side navigatie, WikiWords en comboboxen. Bij tienduizenden objecten worden responsegrootte, browsergeheugen en sorteren merkbaar. Mogelijke vervolgstappen zijn server-side paginering, een compacte referentiecatalogus en lazy loading per namespace.
|
|
|
|
### Volledige versies
|
|
|
|
Iedere pagina- en CMapsave bewaart een volledige snapshot. Opslag groeit lineair; CMap-autosave kan veel bijna gelijke JSONB-documenten opleveren. Meet per object het aantal versies, bytes en savefrequentie. Een later beleid kan oude autosaves uitdunnen terwijl expliciete snapshots en betekenisvolle saves blijven bestaan. Zo'n beleid vereist eerst een expliciete bewaargarantie en back-up.
|
|
|
|
### Bijlagen
|
|
|
|
Bijlagebytes staan in PostgreSQL en worden volledig in geheugen gelezen voor de response. Stel een maximale uploadgrootte in voordat grote media worden ondersteund. Voor echt grote objecten zijn streaming of een object store mogelijk, maar dat verandert back-up, autorisatie en referentiebeheer en is dus geen kleine optimalisatie.
|
|
|
|
### Browserrendering
|
|
|
|
Grote CMaps tekenen veel DOM/SVG-objecten en connectors. Volledige kaarten hebben uiteindelijk layoutkosten die niet met een snellere database verdwijnen. Meet nodeaantal, rendertijd en interactieframes. Sub-CMaps, viewportculling of vereenvoudigde read-only rendering zijn dan gerichte opties.
|
|
|
|
## Meetplan
|
|
|
|
Voeg vóór optimalisatie minimaal deze metingen toe:
|
|
|
|
- requestduur per endpoint en responsebytes;
|
|
- connecttijd versus SQL-tijd;
|
|
- aantallen pagina's, CMaps en versies;
|
|
- gemiddelde en p95 Markdown-, JSONB- en bijlagegrootte;
|
|
- tijd voor CMap-zoekquery's;
|
|
- browserrendertijd bij representatieve CMaps.
|
|
|
|
Gebruik datasets met echte linkdichtheid en documentgroottes. Duizend lege pagina's voorspellen het gedrag van duizend technische documenten niet.
|
|
|
|
## Optimalisatievolgorde
|
|
|
|
De verwachte volgorde bij groei is:
|
|
|
|
1. CMap-zoekvector opslaan en indexeren;
|
|
2. databaseconnectionpool toevoegen;
|
|
3. catalogi pagineren of per namespace laden;
|
|
4. expliciet versie- en uploadbeleid ontwerpen;
|
|
5. pas daarna horizontale of servicegerichte architectuur overwegen.
|
|
|
|
Deze volgorde behoudt de eenvoud van [Structuur en samenhang](racket-wiki:structuur-en-samenhang) zolang die nog waardevol is.
|