Нужно смотреть не только на частный ответ, но и на количество запросов и занимаемое время. Если на 1 запрос отдается ответ 500мс и это крупный отчет, то вполне приемлемое время. А если это лишь десятая часть от всех запросов и от этого тормозит отрисовка на клиенте, то это никуда не годится. Оптимально отдать ответ так, чтобы клиент получил его до 100 мс. Свыше этого клиент уже замечает время отклика.
Тело GET запроса 835кб
Это довольно большой размер для ответа и поэтому требуется сначала его сформировать, а потом отдать клиенту.
Можно вместо этого заранее формировать ответ (в фоне очередями), а при запросе - отдавать готовый ответ. Или если возможно, ставить задачу в очередь и информировать клиента о необходимости ждать и тогда по выполнении задачи выдать ссылку на скачивание или на месте выдать готовый ответ.
уходит 0,36сек - 0.4cек, из них на преобразования результатов из Redis в коде Python 0.26сек (преобразование байтов в строку, строки в структуру вложенных списков, проход по этим спискам и т.д.)
Возможно, в Redis данные хранятся в неоптимальном виде. Может, надо подумать как хранить так, чтобы обработка данных не занимала так много времени. А, может, вообще, хранить данные в реляционной СУБД. Попробовать сохранить данные в материализованном представлении, чтобы не тратить время на отдачу ответа.