Что считаете долгим запросом на стороне веб-сервера?
У меня критерий, что запрос не должен обрабатываться дольше 100 милисекунд. Если дольше - оптимизируем, кешируем, переделываем, далее - везде. На самом деле, в большинстве случаев и 100 мс достаточно много, но все зависит от нагрузки на сервер, количества RPS и прочей фигни.
Одна десятая секунды - это комфортный ответ для любого пользователя, по хорошему сюда еще добавлется куча всякого времени на: передачу данных, рендеринг браузера, запуск JS, отрисовку...
В итоге: на все про все хорошо бы уложиться в 200-400 мс.
Нужно смотреть не только на частный ответ, но и на количество запросов и занимаемое время. Если на 1 запрос отдается ответ 500мс и это крупный отчет, то вполне приемлемое время. А если это лишь десятая часть от всех запросов и от этого тормозит отрисовка на клиенте, то это никуда не годится. Оптимально отдать ответ так, чтобы клиент получил его до 100 мс. Свыше этого клиент уже замечает время отклика.

Тело GET запроса 835кбЭто довольно большой размер для ответа и поэтому требуется сначала его сформировать, а потом отдать клиенту.
Можно вместо этого заранее формировать ответ (в фоне очередями), а при запросе - отдавать готовый ответ. Или если возможно, ставить задачу в очередь и информировать клиента о необходимости ждать и тогда по выполнении задачи выдать ссылку на скачивание или на месте выдать готовый ответ.

уходит 0,36сек - 0.4cек, из них на преобразования результатов из Redis в коде Python 0.26сек (преобразование байтов в строку, строки в структуру вложенных списков, проход по этим спискам и т.д.)Возможно, в Redis данные хранятся в неоптимальном виде. Может, надо подумать как хранить так, чтобы обработка данных не занимала так много времени. А, может, вообще, хранить данные в реляционной СУБД. Попробовать сохранить данные в материализованном представлении, чтобы не тратить время на отдачу ответа.