Dette er en sammenligning mellem æbler og appelsiner. Se http://redis.io/topics/benchmarks
Redis er en effektiv fjernbetjening datalager. Hver gang en kommando udføres på Redis, sendes en besked til Redis-serveren, og hvis klienten er synkron, blokerer den for at vente på svaret. Så ud over omkostningerne ved selve kommandoen, betaler du for en netværksrejse eller en IPC.
På moderne hardware er netværksrejser eller IPC'er overraskende dyre sammenlignet med andre operationer. Dette skyldes flere faktorer:
- mediets rå latenstid (hovedsageligt til netværk)
- forsinkelsen af styresystemplanlæggeren (ikke garanteret på Linux/Unix)
- Hukommelsescache-misser er dyre, og sandsynligheden for cache-misser øges, mens klient- og serverprocesserne er planlagt ind/ud.
- på avancerede kasser, NUMA bivirkninger
Lad os nu gennemgå resultaterne.
Ved at sammenligne implementeringen ved hjælp af generatorer og den, der anvender funktionskald, genererer de ikke det samme antal rundrejser til Redis. Med generatoren har du blot:
while time.time() - t - expiry < 0:
yield r.get(fpKey)
Altså 1 tur/retur pr. iteration. Med funktionen har du:
if r.exists(fpKey):
return r.get(fpKey)
Altså 2 rundrejser pr. iteration. Ikke underligt, at generatoren er hurtigere.
Det er selvfølgelig meningen, at du skal genbruge den samme Redis-forbindelse for optimal ydeevne. Det nytter ikke at køre et benchmark, som systematisk forbinder/afbryder.
Endelig, hvad angår ydeevneforskellen mellem Redis-opkald og fillæsningen, sammenligner du blot et lokalt opkald med et fjernopkald. Fillæsninger cachelagres af OS-filsystemet, så de er hurtige hukommelsesoverførselsoperationer mellem kernen og Python. Der er ingen disk I/O involveret her. Med Redis skal du betale for omkostningerne ved rundrejserne, så det er meget langsommere.