У меня Apache работает на четырехъядерном сервере Ubuntu на ADSL со скоростью 384 кбит / с. Файлы загружаются пользователями через веб-форму и обрабатываются различными программами Python, работающими как сценарии CGI. Некоторые сценарии интенсивно загружают процессор и запускаются на 100% (на одном ядре) в течение нескольких минут; они отправляют результаты пользователю по электронной почте, чтобы сеанс HTTP не оставался открытым. Некоторые сценарии требуют загрузки файлов большего размера (всего несколько МБ). В настоящее время использование очень низкое, с несколькими обращениями в день и очень немногими, если они вообще есть, экземплярами или более чем пользователями, использующими сервисы одновременно. В среднесрочной перспективе мне нужно будет сделать эти услуги доступными для большего числа пользователей.
Я подозреваю, что построенная мною инфраструктура нелегко поддается масштабированию. Например, один пользователь попросил меня разрешить загрузку нескольких файлов в программу, интенсивно использующую процессор. Это означает, что машина будет занята в течение более длительного периода времени. Если другой пользователь также загрузил несколько файлов в один и тот же сценарий, машина может стать очень загруженной на еще более длительный период.
Я знаю, что здесь нельзя использовать дискуссионные вопросы, поэтому я хотел бы задать следующие конкретные вопросы:
Какие стратегии или подходы мне нужно будет рассмотреть, чтобы сделать эти услуги масштабируемыми, то есть нужно ли мне полностью переосмыслить инфраструктуру?
Если я не внесу изменений и 10 человек загрузят каждый по 10 файлов в программу, интенсивно использующую процессор, например, все ли 10 потоков, созданных сценарием CGI, просто будут успешно (если медленно) работать со всеми 10 входными файлами? «Безопасно» ли иметь сервер, работающий со 100% загрузкой ЦП в течение часа, двух или трех?
Для начала вам следует подумать об использовании WSGI интерфейс для вашего приложения, затем рассмотрите возможность реализации некоторой библиотеки, управляемой асинхронными событиями, например Celery или gevent для планирования вашего приложения logix в задачах.
CGI - это самый старый и самый неэффективный способ вызова внешнего кода, как с точки зрения памяти, так и с точки зрения гибкости, пересмотрите свой проект, чтобы использовать любую из микро-фреймворков python (например, bottle.py или flask), это даст вам гораздо более стабильную среду, к которой вы можете подключить логику (ваш код Python) для работы с ранее упомянутыми библиотеками.
Если ваш питон хорошо написан и имеет приличную модульную структуру, это не должно быть так уж плохо.
Что вам нужно сделать, это посмотреть Сельдерей, и использовать его как очередь заданий.
Когда пользователь отправляет файл на обработку, он ставится в очередь на Celery, а затем будет обработан либо на том же сервере, либо на рабочем узле, когда ресурсы доступны. Celery обычно поддерживается RabbitMQ или Redis в качестве брокера сообщений (фактического сервера очереди), и их относительно легко масштабировать.
Что касается обратного вызова «работа завершена», здесь доступно множество различных опций, вы все равно можете использовать электронную почту или вы можете посмотреть на такую услугу, как Толкатель для отправки уведомлений обратно в браузер отправившего пользователя.
На самом деле серверы рассчитаны на работу при загрузке процессора 80-90%. Я имею в виду, что именно здесь вы максимально используете вложенную мощность (вроде как).
Однако я подозреваю, что вы размещаете это из дома (отсюда медленный восходящий канал ADSL), и что на самом деле это может быть просто повторно используемый настольный ПК, которые не подходят для рабочих циклов и нагрузки серверного типа.