Comments 23
Конечно, если бы вы использовали не JSON, а скажем, Protobuf или Cap'n Proto, у вас бы все работало еще быстрее.
Несмотря на то, что SIMD "на вас работает", вы его не используете, а просто выбрали самую быструю либу из доступных. Если бы она работала на "адском пламени" - вам бы от этого было бы ни холодно, ни жарко, потому как цель ваша была просто "более быстрые лошади". В этом смысле хидер слегка бэйтный и мислидинг (на мой взгляд).
Конечно, если бы можно было запустить protobuf на старых smarttv, мы бы так и сделали. Но здесь вступают в силу ограничения вендоров.
На счет SIMD. Понял возмущение, но увы, не понял в чем. В формулировке? Так SIMD использовался так же, как и любые другие возможности процессоров. Скажем, тот же LLVM сам использует SIMD при компиляции там, где может, даже если вы в коде не использовали AVX intrinsics.
Ну так про то и речь, что SIMD используется автоматически. Вы же не пишете, как Вы используете другие фичи современных процессоров для ускорения TLS? А ведь без них у вас bottleneck был бы в TLS...
Интересно что за данные вы отдаете, что сериализация занимает более 0.1% общего времени ответа и оптимизация именно этого блока важно для прироста.
В этом случае речь идёт о расписании телепередач, там множество метаданных и передача данных между сервисами тоже в JSON (позже заменили на Protobuf). Можно было бы оптимизировать формат данных и отдвавать что-то более компактное в более компактном API, но увы, около 40% клиентских приложений просто не обновить, а остальные обновляются медленно.
orJSON одобряю. Сам везде его использую. А кроме него странно, что вы оптимизируете инфраструктуру, а не саму Django, где прирост будет не в проценты а в разы. Особенно это ощутимо в случае DRF. Я делал несколько раз доклад о Django-FTL, наборе методик, убыстряющих, например, формы Django или Serializers DRF в 60 раз, как и о простых настройках Django которые тронь и всё развалится взлетит.
Серверы приложений стали обрабатывать до 3-х раз больше запросов в секунду на том же железе
А кэш поместили туда-же или это дополнительное железо?
После анализа передаваемых и используемых данных, стало ясно, что часть данных можно не запрашивать из БД, сокращая время обработки запроса и генерации ответа. Это позволило сократить объем ответа некоторых методов до 20% (профиль пользователя, метаданные контента).
Я как-то оптимизировал один процесс, который падал по памяти, там 99% данных вытащенных из базы не использовались. Одна из самых лёгких оптимизаций м в моей жизни.
Разобрав цепочку запросов пользователя стало ясно, что несколько последовательных запросов требуют получения одних и тех же данных из профиля пользователя: наличие подписок и дополнительных покупок, привязку его к интернет-провайдеру, регион и др.
К экстремально пиковым нагрузкам можно привязать высокоуровненый кэш:
Этот пользователь может смотреть это видео. И под нужные даты его предзаполнять.
Очень странно читать про SIMD и Джангу, приправленную DRF. SIMD - это когда у вас гигабайты данных в секунду, причем эти гигабайты идут непрерывным потоком, и пока ваш DRF сформирует модельку, SIMD уже пару сотен мегабайт может проглодить, так что вы не в те ворота вошли. Это даже не из пушки по воробья, а какой нибудь межконтинентальной ракетой с ядерным зарядом по муравьям. А если у вас GC нагружен, то SIMD вам мало чем поможет, так как у вас много аллокаций и видимо нужно код переписывать. Может быть вам стоит попробовать jsonl, чтобы не вкорячивать в память длинные списки джейсона.
Ну попробуйте взять pypy, он вам реально бустанет производительность. Мой парсер на питоне работает на нём в 5 раз быстрее.
Асинхронный код можно запускать и на классической джанге, путем сосздания своего эвент лупа.
Я уже молчу про то, что можно pydantic заюзать, хотя бы для рест клиентов, его на раст переписали.
Короче, у вас инструменты на которых можно быстро прототипировать, но когда нагрузка растет, стоит посмотреть на более производительные решения и вынести нагруженные части в отдельные сервисы.
его на раст переписали
Из-за чего он работает медленнее чем чистый питон?)
Как я упоминал ранее - SIMD здесь не самоцель, а просто приятный бонус. Самое важное - это росто производительности минимальными изменениями в коде используя максимум от доступного железа.
Как итог самые нагруженные части и были вынесены в сервисы на Go.
Самое главное, что у любого бизнеса есть ограничения и иногда нет ресурсов на вынесение логики из огромного монолита в нужный срок. Приходится искать решения, которые устроят вас здесь и сейчас, закладывая длительные изменения в план.
Оптимизация Django под высокие нагрузки: как мы ускорили ответы сервиса с помощью кэша, SIMD и настройки GC