Toto je srovnání jablek s pomeranči. Viz http://redis.io/topics/benchmarks
Redis je efektivní dálkové ovládání úložiště dat. Pokaždé, když je na Redis vykonán příkaz, je odeslána zpráva na server Redis, a pokud je klient synchronní, zablokuje čekání na odpověď. Takže kromě nákladů na samotný příkaz budete platit za zpáteční síť nebo IPC.
Na moderním hardwaru jsou zpáteční sítě nebo IPC překvapivě drahé ve srovnání s jinými operacemi. To je způsobeno několika faktory:
- hrubá latence média (hlavně pro síť)
- latence plánovače operačního systému (není zaručena v systémech Linux/Unix)
- Chyby mezipaměti jsou drahé a pravděpodobnost vynechání mezipaměti se zvyšuje, když jsou procesy klienta a serveru naplánovány dovnitř a ven.
- na krabicích vyšší třídy, NUMA vedlejších účinků
Nyní se podívejme na výsledky.
Při porovnání implementace využívající generátory a implementace využívající volání funkcí negenerují stejný počet zpátečních cest do Redis. S generátorem jednoduše máte:
while time.time() - t - expiry < 0:
yield r.get(fpKey)
Takže 1 zpáteční cesta za iteraci. S funkcí máte:
if r.exists(fpKey):
return r.get(fpKey)
Takže 2 zpáteční cesty za iteraci. Není divu, že je generátor rychlejší.
Pro optimální výkon byste samozřejmě měli znovu použít stejné připojení Redis. Nemá smysl spouštět benchmark, který se systematicky připojuje/odpojuje.
A konečně, pokud jde o rozdíl ve výkonu mezi voláními Redis a čtením souboru, jednoduše porovnáváte místní volání se vzdáleným voláním. Čtení souborů jsou ukládána do mezipaměti souborovým systémem OS, takže jde o operace rychlého přenosu paměti mezi jádrem a Pythonem. Není zde zapojen žádný diskový I/O. S Redis musíte platit za zpáteční lety, takže je to mnohem pomalejší.