Моя компания использует redis на пути, довольно критичном к производительности. Сервер nginx обращается к нему один раз за запрос. Сам вызов имеет несколько аргументов, размер которых в настоящее время равен 80 байтам. Этот вызов передается по сети в redis, который передает аргументы загруженному сценарию lua, а затем принимает решение и возвращает его.
Мой босс считает, что добавление дополнительной 32-байтовой строки к этим аргументам неприемлемо плохо по сравнению с жестким кодированием строки в lua-скрипте (что отстойно по другим причинам), потому что «если мы получим 50 тысяч запросов в секунду, это 1,6 ГБ дополнительной сети. трафик в ту секунду ". Моя интуиция подсказывает, что это не проблема. Трафик идет от экземпляра EC2 к экземпляру ElastiCache, и я думаю, что из-за того, как работают пакеты и насколько мал уже запрос, эти 32 дополнительных байта вряд ли повлекут за собой значительные затраты на обработку в сетевом стеке на обоих концах. Я совершенно не прав?
Производительность
На производительность всего приложения это никак не повлияло. Вы можете потратить много времени на микротест. Однако, поскольку вы увеличиваете запрос в одном месте, это может иметь волновой эффект во всем приложении. Пока вы не увеличиваете количество IP-пакетов, снижение производительности может быть минимальным, если задержка в сети высока. Итог, ориентир. Оставьте в коде возможность выбора, какую реализацию вы будете использовать во время выполнения (например, вариант переключения).
Качество кода
Обычно важнее иметь код хорошего качества и пространство для расширения приложения, чем ограничивать себя. Позже вы можете разработать фильтр, который минимизирует, сжимает, кэширует и т. Д. Ваш трафик для Redis, что поможет вам получить больше скорости, чем небольшая оптимизация.