12

Превысил ли Django 100 тыс. посещений в день? [закрыто]

17

Проблема:

Я разрабатываю веб-приложение на Django и изначально выбрал этот фреймворк по ряду причин:

  • Я хотел использовать бесплатные и открытые инструменты.
  • Мне нравится Python, и я считаю, что это долгосрочный язык. В то же время я не был уверен в Ruby, а изучение PHP показалось мне слишком сложным.
  • Я создаю прототип для своей идеи и не задумываюсь о будущем. Скорость разработки была основным фактором, и я уже знал Python.
  • Я знал, что миграция на Google App Engine будет проще, если я решу сделать это в будущем.
  • Я слышал, что Django "хороший".

Теперь, когда я приближаюсь к публикации своего проекта, начинаю беспокоиться о масштабируемости. Единственная информация, которую я нашел о возможностях масштабирования Django, предоставлена командой Django. Я не хочу умалять их заслуги, но, очевидно, эта информация не является объективной.

Существуют ли независимые команды разработчиков, которые сообщили о создании сайта на Django, который надежно обрабатывает более 100 000 посещений в день?

5 ответ(ов)

2

Мы сейчас проводим нагрузочное тестирование. Мы считаем, что можем поддерживать 240 параллельных запросов (устойчивый уровень 120 запросов в секунду круглосуточно) без значительного ухудшения производительности сервера. Это будет 432,000 запросов в час. Времена ответа не маленькие (наши транзакции большие), но при увеличении нагрузки наше базовое время отклика остается на прежнем уровне.

Мы используем Apache в сочетании с Django и MySQL. Операционная система — Red Hat Enterprise Linux (RHEL), 64-битная. Мы используем mod_wsgi в режиме демона для Django. Никакой оптимизации кэша или базы данных, кроме принятия настроек по умолчанию, не проводилось.

Вся система работает на одной виртуальной машине на 64-битном Dell с (думаю) 32 Гб ОЗУ.

Так как производительность практически такая же как при 20, так и при 200 параллельных пользователях, нам не нужно тратить много времени на "настройки". Вместо этого нам просто нужно поддерживать нашу базовую производительность за счет обычных улучшений производительности SSL, нормального проектирования и реализации базы данных (индексирование и т. д.), улучшений производительности фаервола и т. д.

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

0

Обратите внимание, что если вы ожидаете 100 000 пользователей в день, которые будут активны в течение нескольких часов (что означает более 20 000 одновременных пользователей), вам потребуется ОЧЕНЬ МНОГО серверов. Например, StackOverflow имеет около 15 000 зарегистрированных пользователей, и большинство из них, вероятно, не активны ежедневно. В то время как основная часть трафика поступает от незарегистрированных пользователей, я полагаю, что очень немногие из них остаются на сайте более нескольких минут (т.е. они следуют по результатам поиска в Google и затем уходят).

Для такого объема ожидайте как минимум 30 серверов... что всё равно составляет довольно высокую нагрузку — 1 000 одновременных пользователей на сервер.

0

Не думаю, что проблема связана именно со масштабированием Django.

Я настоятельно рекомендую вам обратить внимание на свою архитектуру — именно это поможет вам решить задачи масштабирования. Если архитектура окажется неправильной, то не имеет значения, насколько хорошо работает Django. Производительность != Масштабируемость. Вы можете создать систему с великолепной производительностью, но хорошее масштабирование не обеспечится, и наоборот.

Является ли ваша база данных "узким местом" в приложении? Если да, то именно там кроются ваши проблемы с масштабируемостью. Как вы планируете взаимодействовать с базой данных из Django? Что произойдет, если база данных не сможет обрабатывать запросы так же быстро, как их будет принимать Django? Что будет, если ваши данные выйдут за пределы одной физической машины? Вам нужно заранее продумать, как вы собираетесь справляться с такими обстоятельствами.

Кроме того, что произойдет, если трафик превысит возможности одного серверного приложения? Управление сессиями в таком случае может быть сложным, и чаще всего вам потребуется архитектура "shared nothing". Однако это зависит от вашего приложения.

Вкратце, язык программирования не является определяющим фактором для масштабируемости; язык в первую очередь отвечает за производительность (и это также зависит от вашего приложения — разные языки показывают разные результаты). Ваш дизайн и архитектура делают масштабирование реальным.

Надеюсь, это поможет. Буду рад ответить на дополнительные вопросы, если они у вас есть.

0

Еще одним примером является rasp.yandex.ru — российский сервис расписаний транспорта. Его посещаемость соответствует вашим требованиям.

0

Я разрабатываю сайты с высоким трафиком на Django для национального вещателя в Ирландии. У нас это работает хорошо. Создание высокопроизводительного сайта — это не только выбор фреймворка. Фреймворк — это лишь одна часть системы, которая столь же сильна, как её weakest link (слабое звено). Использование самого нового фреймворка 'X' не решит ваши проблемы с производительностью, если они связаны с медленными запросами к базе данных или неправильно настроенным сервером или сетью.

Чтобы ответить на вопрос, пожалуйста, войдите или зарегистрируйтесь