Това е сравнение между ябълки и портокали. Вижте http://redis.io/topics/benchmarks
Redis е ефективнодистанционно съхранение на данни. Всеки път, когато командата се изпълнява на Redis, се изпраща съобщение до сървъра на Redis и ако клиентът е синхронен, той блокира чакането на отговор. Така че освен цената на самата команда, вие ще платите за мрежово двупосочно пътуване или IPC.
При съвременния хардуер мрежовите двупосочни пътувания или IPC са изненадващо скъпи в сравнение с други операции. Това се дължи на няколко фактора:
- необработената латентност на носителя (главно за мрежа)
- латентността на планировчика на операционната система (не е гарантирана за Linux/Unix)
- Пропуските в кеша на паметта са скъпи и вероятността от пропуски в кеша се увеличава, докато процесите на клиента и сървъра са планирани за влизане/излизане.
- на кутии от висок клас, NUMA странични ефекти
Сега нека прегледаме резултатите.
Сравнявайки реализацията, използваща генератори, и тази, използваща извиквания на функции, те не генерират същия брой обръщания към Redis. С генератора просто имате:
while time.time() - t - expiry < 0:
yield r.get(fpKey)
Така че 1 двупосочно пътуване на итерация. С функцията имате:
if r.exists(fpKey):
return r.get(fpKey)
Така че 2 двупосочни пътувания на итерация. Нищо чудно, че генераторът е по-бърз.
Разбира се, трябва да използвате повторно същата връзка Redis за оптимална производителност. Няма смисъл да се изпълнява бенчмарк, който систематично свързва/прекъсва.
И накрая, по отношение на разликата в производителността между извикванията на Redis и четенията на файла, вие просто сравнявате локално повикване с отдалечено. Четенията на файлове се кешират от файловата система на ОС, така че те са бързи операции за прехвърляне на памет между ядрото и Python. Тук няма дисков вход/изход. С Redis трябва да плащате за разходите за двупосочно пътуване, така че е много по-бавно.
