opensim-addon-modules-exp/modules/OpenSimConcurrentFlotsamAssetCache/COMPARISON.MD

COMPARISON

Comparison to FlotsamAssetCache (ENG)

Aspect	ConcurrentFlotsamAssetCache	FlotsamAssetCache (Core)
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	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; 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 und schnelle Datenträger; nutze Core, wenn Einfachheit, geringer Ressourcenbedarf und Wartbarkeit im Vordergrund stehen.