To jest porównanie jabłek do pomarańczy. Zobacz http://redis.io/topics/benchmarks
Redis to wydajny zdalny magazyn danych. Za każdym razem, gdy polecenie jest wykonywane na Redis, wiadomość jest wysyłana do serwera Redis, a jeśli klient jest synchroniczny, blokuje oczekiwanie na odpowiedź. Więc poza kosztem samego polecenia, zapłacisz za podróż w obie strony lub IPC.
Na nowoczesnym sprzęcie, połączenia sieciowe lub IPC są zaskakująco drogie w porównaniu z innymi operacjami. Wynika to z kilku czynników:
- surowe opóźnienie medium (głównie dla sieci)
- opóźnienie harmonogramu systemu operacyjnego (nie gwarantowane w systemie Linux/Unix)
- Błędy w pamięci podręcznej są drogie, a prawdopodobieństwo braków w pamięci podręcznej wzrasta, gdy procesy klienta i serwera są planowane we/wy.
- na high-endowych pudełkach, efekty uboczne NUMA
Przyjrzyjmy się teraz wynikom.
Porównując implementację wykorzystującą generatory i tę wykorzystującą wywołania funkcji, nie generują one takiej samej liczby roundtrips do Redis. Z generatorem po prostu masz:
while time.time() - t - expiry < 0:
yield r.get(fpKey)
A więc 1 podróż w obie strony na iterację. Dzięki tej funkcji masz:
if r.exists(fpKey):
return r.get(fpKey)
Tak więc 2 podróże w obie strony na iterację. Nic dziwnego, że generator jest szybszy.
Oczywiście powinieneś ponownie użyć tego samego połączenia Redis, aby uzyskać optymalną wydajność. Nie ma sensu uruchamiać testu porównawczego, który systematycznie łączy/rozłącza.
Wreszcie, jeśli chodzi o różnicę wydajności między wywołaniami Redis a odczytami pliku, po prostu porównujesz wywołanie lokalne z wywołaniem zdalnym. Odczyty plików są buforowane przez system plików systemu operacyjnego, więc są to operacje szybkiego transferu pamięci między jądrem a Pythonem. W tym przypadku nie ma żadnego dysku I/O. W przypadku Redis musisz zapłacić za koszty podróży w obie strony, więc jest to znacznie wolniejsze.
