Джанго масштабируется? [закрыто]

Мой опыт работы с Django минимален, но я помню, что в книге «Django Book» есть глава, в которой они беседуют с людьми, использующими некоторые из более крупных приложений Django. Вот ссылка. Я полагаю, это может дать некоторую информацию.

В нем говорится, что curse.com - одно из крупнейших приложений Django с примерно 60-90 миллионами просмотров страниц в месяц.

Другой пример - rasp.yandex.ru, служба расписания транспорта России. Его посещаемость удовлетворит ваши требования.

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

Для этого объема ожидается не менее 30 серверов ... что по-прежнему довольно тяжело - 1000 одновременных пользователей на сервер.

Масштабирование веб-приложений - это не веб-фреймворки или языки, а ваша архитектура. Речь идет о том, как вы обрабатываете кеш браузера, кеш базы данных, как используете нестандартные поставщики сохраняемости (например, CouchDB ), насколько настроена ваша база данных и многое другое ...

We're doing load testing now. We think we can support 240 concurrent requests (a sustained rate of 120 hits per second 24x7) without any significant degradation in the server performance. That would be 432,000 hits per hour. Response times aren't small (our transactions are large) but there's no degradation from our baseline performance as the load increases.

We're using Apache front-ending Django and MySQL. The OS is Red Hat Enterprise Linux (RHEL). 64-bit. We use mod_wsgi in daemon mode for Django. We've done no cache or database optimization other than to accept the defaults.

We're all in one VM on a 64-bit Dell with (I think) 32Gb RAM.

Since performance is almost the same for 20 or 200 concurrent users, we don't need to spend huge amounts of time "tweaking". Instead we simply need to keep our base performance up through ordinary SSL performance improvements, ordinary database design and implementation (indexing, etc.), ordinary firewall performance improvements, etc.

What we do measure is our load test laptops struggling under the insane workload of 15 processes running 16 concurrent threads of requests.

Я уверен, что вы ищете более надежный ответ, но наиболее очевидное объективное подтверждение, которое я могу придумать, заключается в том, что Google подталкивает Django к использованию с его App Engine фреймворк. Если кто-то знает о масштабируемости и занимается ею регулярно, так это Google. Судя по тому, что я читал, наиболее ограничивающим фактором является внутренняя часть базы данных, поэтому Google использует свои собственные ...

Да, может. Это может быть Django с Python или Ruby on Rails. Он по-прежнему будет масштабироваться.

Есть несколько разных техник. Во-первых, кеширование - это не масштабирование. У вас может быть несколько серверов приложений, сбалансированных с nginx в качестве передней в дополнение к аппаратному балансировщику (-ам). Для масштабирования на стороне базы данных вы можете довольно далеко пойти с ведомым устройством чтения в MySQL / PostgreSQL, если вы пойдете по пути РСУБД.

Вот несколько хороших примеров веб-сайтов с интенсивным трафиком в Django:

• Pownce когда они были
• Discus (общий менеджер общих комментариев)
• Все сайты, связанные с газетами: Washington Post и др.

Вы можете чувствовать себя в безопасности.

Самый крупный сайт django, о котором я знаю, - это Washington Post , что определенно указывает на то, что он может хорошо масштабироваться.

Хорошие дизайнерские решения, вероятно, имеют большее влияние на производительность, чем что-нибудь еще. Twitter часто упоминается как сайт, который воплощает проблемы производительности с другой веб-фреймворком на основе динамического интерпретируемого языка, Ruby on Rails, однако инженеры Twitter заявили, что этот фреймворк не является такой большой проблемой, как некоторые из вариантов дизайна базы данных, которые они сделали раньше. на.

Django очень хорошо работает с memcached и предоставляет несколько классов для управления кешем, с помощью которых можно решить большинство проблем с производительностью. То, что вы доставляете по сети, на самом деле почти более важно, чем ваша серверная часть - использование такого инструмента, как yslow, критически важно для высокопроизводительного веб-приложения. Вы всегда можете добавить больше оборудования на свой сервер, но вы не можете изменить пропускную способность пользователей.

Немного поигравшись в адвоката дьявола:

Вам следует проверить Основной доклад DjangoCon 2008 , представленный Кэлом Хендерсоном под заголовком «Почему я ненавижу Django », где он подробно описывает все, чего не хватает Django, что вы, возможно, захотите сделать на веб-сайте с высокой посещаемостью. В конце концов, вы должны принять все это непредвзято, потому что вполне возможно написать масштабируемые приложения Django, но я подумал, что это хорошая презентация и имеет отношение к вашему вопросу.

На прошлой неделе я был на конференции EuroDjangoCon, и это было предметом нескольких разговоров, в том числе от основателей крупнейшего сайта на основе Django, Pownce (слайды с одного поговорим здесь ). Главное сообщение заключается в том, что вам нужно беспокоиться не о Django, а о таких вещах, как правильное кеширование, балансировка нагрузки, оптимизация базы данных и т. Д.

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

Вы определенно можете запустить сайт с высокой посещаемостью в Django. Ознакомьтесь с этим постом до Django 1.0, но все еще актуальным здесь: http://menendez.com/blog/launching-high-performance-django-site/

Если вы если у вас есть сайт со статическим содержимым, то размещение сервера Varnish впереди значительно повысит вашу производительность. Даже один компьютер может легко выдать 100 Мбит / с трафика.

Обратите внимание, что с динамическим контентом использование чего-то вроде Varnish становится намного сложнее.

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

BidRodeo Penny Auctions - это сайт среднего размера, работающий на Django. Это очень динамичный веб-сайт, который обрабатывает большое количество просмотров страниц в день.

Я нашел эту статью MSDN в быстром поиске Google. Django, безусловно, может делать 100 тысяч обращений в день и более. Но YMMV в том, чтобы разместить ваш конкретный сайт там, в зависимости от того, что вы создаете.

Существуют варианты кэширования на уровне Django (например, кэширование наборов запросов и представлений в memcached может творить чудеса) и за его пределами (восходящий поток кеширует вроде Squid ). Спецификации сервера базы данных также будут важным фактором (и, как правило, местом, где можно потратиться), как и то, насколько хорошо вы его настроили. Не думайте, например, что Django правильно настроит индексы. Не думайте, что конфигурация по умолчанию PostgreSQL или MySQL является правильной.

Кроме того, у вас всегда есть возможность запустить Django на нескольких серверах приложений, если это медленный точка, с программным или аппаратным балансировщиком нагрузки впереди.

Наконец, вы обслуживаете статический контент на том же сервере, что и Django? Вы используете Apache или что-то вроде nginx или lighttpd ? Можете ли вы позволить себе использовать CDN для статического контента? Об этом можно подумать, но все это очень умозрительно. 100 000 обращений в день - не единственная переменная: сколько вы хотите потратить? Какой у вас опыт управления всеми этими компонентами? Сколько у вас времени, чтобы собрать все воедино?

Какой самый "самый большой" сайт, построенный на Django сегодня? (Я измеряю размер в основном по пользовательскому трафику)

В США это был Махало . Мне сказали, что они обрабатывают примерно 10 миллионов уникальных посетителей в месяц. Теперь, в 2019 году, Mahalo работает на Ruby on Rails.

За границей сеть Globo (сеть новостных, спортивных и развлекательных сайтов в Бразилии); Alexa помещает их в топ-100 в мире (в настоящее время около 80-го).

Другие известные пользователи Django включают PBS, National Geographic, Discovery, NASA (фактически, несколько различных подразделений в НАСА) и Библиотеку Конгресса.

Может ли Django обрабатывать 100 тыс. Пользователей в день, каждый из которых посещает сайт на пару часов?

Да, но только если вы правильно написали приложение и у вас достаточно оборудования. Джанго это не волшебная пуля.

Может ли такой сайт, как StackOverflow, работать на Django?

Да (но см. выше).

С точки зрения технологии, легко: см. soclone для одной попытки. С точки зрения трафика, конкуренция привязывает StackOverflow к менее 1 миллиону уникальных посетителей в месяц. Я могу назвать как минимум дюжину сайтов Django с большим трафиком, чем SO.

Посмотрите на этот микро-агрегатор новостей, называемый EveryBlock.

Он полностью написан на Django. На самом деле это люди, которые разработали сам фреймворк Django.

Защитник разработчика для YouTube дал говорить о масштабировании Python на Pycon 2012 , который также имеет отношение к масштабированию Django.

YouTube имеет более чем миллиардов пользователей , а на Python построен YouTube.

Не уверен в количестве ежедневных посещений, но вот несколько примеров больших Django сайты:

• disqus.com ( разговор от djangocon )
• bitbucket.org ( написать )
• lanyrd.com ( исходный код )
• support.mozilla.com ( исходный код )
• addons.mozilla.org ( исходный код ) ( разговор от djangocon )
• theonion.com ( написать )
• Система комментариев guardian.co.uk использует Django ( источник )
• instagram
• pinterest
• rdio

Вот ссылка на список сайтов Django с высоким трафиком на Quora .