Меня интересует развертывание приложения django с его базой данных. Итак, я хотел бы знать, что вы думаете, что может быть лучше с точки зрения производительности: три линода 540 (720) или один линод 1440 (2880).
Я хотел бы, чтобы один служил статическим контентом, другой - сервером приложений, а последний - сервером базы данных.
Что вы посоветуете?
Я с уважением не согласен с предложением хаоса. Наличие нескольких VPS не будет распределять нагрузку равномерно, а VPS, обслуживающий статические файлы, вероятно, будет использоваться недостаточно. Также это увеличивает сложность вашего приложения.
Я бы выбрал большой и толстый сервер, увеличивал его емкость по мере необходимости и рассматривал возможность разбиения только тогда, когда его уже невозможно обновить.
Я бы пошел с тремя. Если они будут развернуты на одном сервере, вы немного потеряете производительность по сравнению с одним VPS, но 1) они, вероятно, не будут, 2) их будет легче настроить для их ролей, чем настроить один VPS для всех их ролей, и 3) это означает, что ваше приложение будет разработано для распределенных ролей с первого дня, так что, если вам нужно будет позже стать более мощным, возможно, разверните настоящий сервер для каждой роли, вы готовы к этому .
Я изменю тенденцию и скажу, что вам следует выбрать 2 - 1 для вашего веб-контента и еще один (вероятно, большего размера) для вашей БД. Черт, я в ситуации, когда я использую один VPS для всех своих нужд, включая БД, с соответствующими настроенными поддоменами:
static.example.org: обрабатывает css, js, изображения и т. д. содержимое. Устанавливается с активным хранением и истекает будущее. (контент не истекает в течение года или более, поэтому дальнейшие запросы не выполняются. Сохранение активности включено, поскольку большинство просмотров веб-страниц будут пытаться загрузить много статических страниц, поэтому это ускорит эти запросы)
www.example.org: обрабатывать динамические запросы. Отделение статических запросов от динамических важно для будущей масштабируемости вашей системы - и это не так уж важно для предварительной оптимизации. Установите с выключенными keep-alives и будущим истечением. (Проверка содержимого должна происходить с динамическим содержимым. Отключение keep-alives (или очень низкий уровень) позволяет вам сохранять соединения для входящих запросов ... особенно когда многие попадания будут одиночными и более медленными запросами на просмотр.)
Использование nginx в качестве внешнего прокси, который сам обрабатывает запросы static.example.org, но передает запросы www.example.org на серверную часть FastCGI (например), оказалось для нас быстрым решением - и консервативным для памяти. слишком. В качестве альтернативы вы можете поместить весь свой статический контент на Amazon S3 или что-то в этом роде и вместо этого указать свои веб-страницы (с истечением срока действия в будущем).
Моей первой точкой расширения, вероятно, будет перенос моей БД на отдельный сервер. Я смогу достаточно легко масштабировать процессы FastCGI веб-сервера на несколько систем с помощью nginx - распределение нагрузки должно быть довольно простым ... теоретически.
-Vps имеет программы-убийцы памяти, которые превышают один выделенный RAM. -Нет журналов для проверки в системе. -и если нашим приложениям нужно больше памяти, мы требуем RAM, а провайдеры хостинга требуют денег. -Лучший вариант для VPS среднего размера, распределенный сервер db-приложений.