Динамический контент Django в среде VPS - когда мне нужна очередь? - PullRequest
0 голосов
/ 20 сентября 2009

У меня есть некоторый контент Django, который я планирую разместить на VPS, в Интернете. Он динамически генерирует изображения, которые кэшируются на диск (регенерация не требуется часто, за исключением того, что (1) пользователь изменяет содержимое в изображении или (2) макет обновляется глобально, поэтому все изображения нуждаются в регенерации) прямо сейчас, когда пользователь запрашивает представление, он проверяет чтобы увидеть, является ли то, что хранится на диске, самым последним (т. е. глобальный макет не изменился и пользователь не изменил никакого содержимого) и либо извлекает элемент с диска, либо генерирует новое изображение, сохраняет его и обслуживает его.

Я рассчитал процесс генерации и хранения на диск, и он занимает около 200 мс на недавнем MBP, на котором работает сервер разработки Django. Хотя я не ожидаю огромное количество показов, мне все еще интересно мнение людей относительно обработки такого контента, поэтому у меня есть несколько вопросов:

1) Какие критерии следует использовать, чтобы решить, стоит ли вообще передавать процесс / задачу в систему очередей (rabbitmq и т. Д.), Очевидно, что вы не собираетесь переносить каждую задачу с сервера приложений, поэтому, если ее время заняло, сколько мс, прежде чем его стоит убрать?

2) Я не определился с тем, где его разместить. Если я планирую иметь ряд другого динамического контента, который может быть рассчитан на некоторое время с использованием изображений и тому подобного, лучше ли посоветовать разместить его с помощью, скажем, nginx поверх lighttpd или apache, используя fastcgi, mod_wsgi и т. Д.? Имейте в виду, я планирую разместить на VPS с, скажем, 512-1 ГБ оперативной памяти, и было бы неплохо, если бы сервис изящно деградировал и был какой-то способ предотвратить процесс блокировки сервера, если есть много запросов на новые изображения.

Я планирую провести больше тестов, поскольку я не очень хорошо разбираюсь в этой области, но я хотел бы узнать от людей с этим опытом, в каком направлении лучше смотреть, нет смысла пробовать вещи, о которых известно, что они не работа.

1 Ответ

0 голосов
/ 20 сентября 2009

1) Если у вас достаточно потоков для обработки запросов, вам не нужно беспокоиться об их асинхронной обработке на другом сервере. Тем не менее, если обработка изображения займет много процессорного времени, вы можете делегировать это другому серверу.

2) Хорошей идеей будет разделение подачи статического и динамического контента. Таким образом, если часть генерирования динамического контента начинает испытывать проблемы с производительностью, это не повлияет на обслуживание статического контента.

...