admin/opensim-addon-modules-exp
1
0
Fork 0
mirror of https://github.com/jamenai/opensim-addon-modules-exp.git synced 2026-07-28 13:47:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

update COMPARISON.MD

Browse Source
This commit is contained in:
Lordfox
2025-10-04 12:21:39 +02:00
parent 329241bcde
commit 2ca5800a24
1 changed files with 30 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modules/OpenSimConcurrentFlotsamAssetCache/COMPARISON.MD
+30 -26
View File
@@ -4,36 +4,40 @@
| Aspect | ConcurrentFlotsamAssetCache | FlotsamAssetCache (Core) |
|---|---|---|
| Parallelism | High parallelism for reads/writes; reduced contention | Lower parallelism; possible bottlenecks due to locks/single-writer |
| Latency under load | Lower at peaks; higher throughput | Higher at peaks; waits due to serialization |
| Thundering herd handling | Better coordination of concurrent requests for the same asset | Simpler but may trigger redundant fetches on concurrent requests |
| Consistency/ordering | More complex ordering of touch/replace; careful sync needed | More deterministic; fewer race conditions |
| Debugging/maintenance | More complex, harder to debug | Simpler, easier to reason about |
| Resource usage | Higher (more threads/concurrent structures) | Lower overhead |
| Memory footprint | Slightly higher (concurrent data structures, coordination) | Lower |
| Concurrency risk | Increased risk (livelock/starvation if misconfigured) | Lower risk |
| I/O behavior | More parallel I/O, can better utilize fast storage | More serialized/controlled I/O; predictable but limited throughput |
| Expire/cleanup interaction | More sensitive to LastAccessTime/ordering with parallel updates | Simpler expire logic due to consistent timestamps |
| Parallelism | High parallelism for reads/writes with contention backoff; lock-free maps where possible | Lower parallelism; centralized locks and single-writer patterns |
| Latency under load | Lower at peaks; background writer and non-blocking reads reduce head-of-line blocking | Higher at peaks due to serialization and lock contention |
| Thundering herd handling | In-flight write detection for same file; optional exponential backoff on readers | Simpler; may trigger redundant fetches and waits |
| Consistency/ordering | Careful ordering for touch/replace; atomic replace/move on disk to avoid partials | More deterministic single-path writes; simpler ordering |
| Debugging/maintenance | More complex (multiple caches: weak/memory/file, negative cache, timers) | Simpler (single-path logic) |
| Resource usage | Higher (job engine, timers, concurrent structures) | Lower (fewer moving parts) |
| Memory footprint | Slightly higher (WeakReference map + optional memory cache) | Lower |
| Concurrency risk | More tuning required (starvation/livelock mitigated by backoff caps) | Lower risk by design |
| I/O behavior | Parallel I/O; atomic replace (with optional .bak) and overwrite moves | Serialized I/O; predictable but lower throughput |
| Expire/cleanup | Periodic timer with scene-aware protection and optional .bak cleanup; LastAccessTime updates throttled | Simpler periodic cleanup; fewer edge cases |
| Negative cache | Bounded negative cache with pruning (expiry + oldest sampling) | Typically unbounded/simple or absent |
| Serialization format | Versioned binary format with size caps to guard corruption/OOM | Simpler/legacy formats |
| Fit – large load/cluster | Very good (scales, smooths spikes) | Limited |
| Fit – small setups | May be overkill | Very good (simple, frugal) |
| Overall | Better for high parallelism and throughput with higher complexity | Better for simplicity, predictability, and minimal resources |
| Fit – small setups | Possibly overkill | Very good (simple, frugal) |
| Overall | Optimized for throughput and concurrency with higher complexity | Optimized for simplicity and predictability |
## Vergleich zu FlotsamAssetCache (DEU)
| Aspekt | ConcurrentFlotsamAssetCache | FlotsamAssetCache (Core) |
|---|---|---|
| Parallelität | Hohe Parallelität bei Reads/Writes; weniger Contention | Geringere Parallelität; mögliche Engpässe durch Locks/Single-Writer |
| Latenz unter Last | Niedriger bei Peaks; bessere Durchsatzraten | Höher bei Peaks; Wartezeiten durch Serialisierung |
| Thundering herd Handling | Bessere Koordination gleichzeitiger Zugriffe auf dasselbe Asset | Einfachere, aber potenziell redundante Zugriffe bei gleichzeitigen Requests |
| Konsistenz/Ordnung | Komplexere Ordnung von Touch/Replace; sorgfältige Synchronisation nötig | Deterministischer und einfacher; weniger Race-Conditions |
| Fehlersuche/Wartung | Komplexer, schwieriger zu debuggen | Einfacher, besser nachvollziehbar |
| Ressourcenverbrauch | Höher (mehr Threads/Concurrent-Strukturen) | Geringer (weniger Overhead) |
| Speicherbedarf | Etwas höher (Concurrent-Datenstrukturen, Koordination) | Niedriger |
| Risiko von Concurrency-Bugs | Erhöht (Livelock/Starvation bei falscher Strategie) | Geringer |
| I/O-Verhalten | Mehr paralleler I/O, potenziell bessere Nutzung schneller Speicher | Serieller/koordinierter I/O, planbarer aber limitierter Durchsatz |
| Expire-/Cleanup-Interaktion | Sensibler bzgl. LastAccessTime/Ordnung bei parallelen Updates | Einfachere Expire-Logik durch konsistentere Zeitstempel |
| Eignung – große Last/Cluster | Sehr gut (Skalierung, Spitzen abfedern) | Eingeschränkt |
| Eignung – kleine Setups | Overkill möglich | Sehr gut (einfach, genügsam) |
| Gesamtfazit | Besser für hohe Parallelität und Durchsatz mit höherer Komplexität | Besser für Einfachheit, Vorhersagbarkeit und geringen Ressourcenbedarf |
| Parallelität | Hohe Parallelität bei Reads/Writes; Backoff bei Contention; lock-arme Strukturen | Geringere Parallelität; zentrale Locks/Single-Writer |
| Latenz unter Last | Niedriger bei Peaks; Writer-Worker und non-blocking Reads | Höher bei Peaks durch Serialisierung und Locks |
| Thundering-Herd | Erkennung paralleler Writes je Datei; optionaler Exponential-Backoff für Leser | Einfacher; kann zu redundanten Fetches führen |
| Konsistenz/Ordnung | Sorgfältige Ordnung von Touch/Replace; atomare Replace/Move-Strategien | Deterministischer; einfacher zu überblicken |
| Fehlersuche/Wartung | Komplexer (Weak/Mem/File-Cache, Negative-Cache, Timer) | Einfacher (ein Pfad) |
| Ressourcenverbrauch | Höher (Job-Engine, Timer, Concurrent-Maps) | Geringer |
| Speicherbedarf | Etwas höher (WeakReference-Map + optionaler Memory-Cache) | Niedriger |
| Risiko Concurrency-Bugs | Höher, aber durch begrenzten Backoff/Überwachung mitigiert | Geringer |
| I/O-Verhalten | Paralleler I/O; atomare Replace-Option (.bak optional) und Overwrite-Move | Serieller I/O; planbarer, begrenzter Durchsatz |
| Expire/Cleanup | Periodischer Timer; szenenbewusste Schonung; optionale .bak-Bereinigung; gedrosselte LastAccessTime-Updates | Einfachere Periodik; weniger Randfälle |
| Negative-Cache | Begrenzter Miss-Cache mit Pruning (Ablauf + Sampling der Ältesten) | Einfach/unbegrenzt oder nicht vorhanden |
| Serialisierungsformat | Versioniertes Binärformat mit Größenlimits (Schutz vor Korruption/OOM) | Einfacher/älter |
| Eignung – hohe Last/Cluster | Sehr gut (Skalierung, Peak-Glättung) | Eingeschränkt |
| Eignung – kleine Setups | Mitunter Overkill | Sehr gut (einfach, sparsam) |
| Gesamtfazit | Auf Durchsatz und Parallelität optimiert bei höherer Komplexität | Auf Einfachheit und Vorhersagbarkeit optimiert |
Hinweis: Wähle Concurrent für stark parallelisierte Workloads; nutze Core, wenn Einfachheit und Stabilität wichtiger sind als maximale Skalierung.
Hinweis: Wähle Concurrent für stark parallelisierte Workloads und schnelle Datenträger; nutze Core, wenn Einfachheit, geringer Ressourcenbedarf und Wartbarkeit im Vordergrund stehen.