Как Django может обрабатывать 100 миллионов запросов в день

[granvi]

Статья просто жуть.
Итоговый вывод: Всегда слабое место это БД. По этому оптимизируйте запросы.
Используйте подход Microsoft — не бывает тормозных приложений. Бывает мало вычислительных ресурсов… В помощь всякие докеры и тд. Чтобы быстро решить проблему тормозов приложения. Ведь это фреймворк и в нем скорее всего нельзя в тонкую настройку sql с хинтами и прочими плюшками.
Если оптимизироват запросы, решить проблемы кэширования и разбить на микромервисы с масштабировпнием становится очевидно, что писать можно хоть черта лысого на бейсике.
Ни у одного интерпретатора не будет преимуществ.

[kentavr009]

Разве в статье пропагандируется подобный подход? Там говорится, что хорошо бы иметь возможность добавлять/уменьшать вычислительные ресурсы без остановки сайта, а не только наращивать их. Докеры сегодня так и так используются, если не ошибаюсь. Про хинты не знаю, но делать чистые SQL запросы в нем можно.

[apapacy]

Брокеры не делают этого. Делают оркестраторы. Некоторые оркестра оры например nomad делают это то есть поднимают инстансы как на диване так и без докера

[jonSina]

"Как Django может обрабатывать 100 миллионов запросов в день"
Извиняюсь я из лагеря .net, а что джанго из коробки не может обработать такое ничтожное кол-во запросов? )

[tumbler]

1200 RPS, может, да. Не на всяких там сложных бизнес-процессах, но может, даже на одном сервере.

Статью надо было назвать "как Django может обрабатывать более 3.65 млрд запросов за 10 лет"

[yarmik3d]

Вы сначала напишите такое веб приложение в котором будут востребованы эти 100 миллионов запросов в день. По тестам на среднем сервере Джанго без единой ошибки обрабатывает 67000 запросов в секунду, и это относительно давние тесты, Джанго как python довольно быстро развивается и его производительность довольно таки быстро растет. К слову говоря, сколько сайтов вы создали, что бы хоть 67к запросов в секунду он обрабатывал? И не важно на чем ваш сайт написан. Фейсбук на нем конечно написать можно, но рациональность использования в нем Джанго конечно будет под сомнением.

[alex-khv]

В итоге, со слов автора. Благодаря архитектуре и инфраструктуре, позволяющей динамически масштабировать product name, можно создавать код на чём угодно. Только причём тут заслуга Django ?

[qellex]

Там, кроме этого, еще 7 пунктов, о которых новички могут не знать. Например select_related/prefetch_related — которые начинающие джангисты часто обходят стороной.
Но предназначение этой статьи остается загадкой.

[yarmik3d]

Может потому что статья просто про оптимизацию приложения на Джанго?

[alex-khv]

Повторяюсь. Все эти трюки не Django специфичные. Так что его заслуги тут нет

[yarmik3d]

Какой еще заслуги, статья не о заслугах Django, а об оптимизации Django, что тут не спецефично для Django, select_related не спецефично для него, или встроенные в него приложения и middlewares не спецефично для Django? Вы зачем пишите о том чего не понимаете.

[andreyverbin]

Зашёл поругать бесполезную, шаблонную статью, а тут уже все до меня сказали.

[KirEv]

С началом оглавления

Как Django может

и первом абзаце

1. Инфраструктура решает

с

осуществлять масштабирование

читал по диагонали, в голове был вопрос: каким боком 100млн запросов в день относится к Django, если основная работа за счет масштабирования.

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

А что такое 100млн запросов в день?

день: 60сек*60мин*24часа = 86400сек
запросов в секунду: 100,000,000 / 86400 = 1157,407407407
хорошо, округлим, 1158 запросов в секунду…
1158 запросов в секунду! Карл! Are you kidding me?

Ради справедливости: както по пьяни с другом решили покодить, написал на golang простой апи-сервис за 5мин который делает:
1. глупость: принимает запрос, после таймаута 2сек (эмуляция полезной работы) отдает ОК
2. просто отдает ОК ничего не делая
Скомпилировал под ARM и запустил бинарник на роутере через ssh прямо в терминале
Результат:
1. RPS 1500-2000
2. RPS около 5000
На борту роутера ARMv7 rev 5 (1.5GHz) и 128MB ОЗУ

А вы ради 1.2к RPS такой движ затеяли!

Простите, бомбит!

Спасибо, конечно, за труд в переводе!

Но блин! Опять бомбит!

9. Уменьшите передачу данных между своим API и клиентами

Порождения Ада неявности, когда апи возвращает один объекта как `{«ID»:«123»}`, а другой со всеми возможными и непустыми свойствами объекта, получи массив струганины, экономя на спичках выносим мозг и глаз разрабам которые работают с этим апи.

ОЙ, короче…

[yarmik3d]

Вы какую то ерунду сморозили, просто принять запрос и обработать с изменениями в БД это вообще не одно и то же, так что бомбит у вас не из-за статьи, а по какой то другой причине.

[kentavr009]

Почитал комменты и понял, что англоязычные разработчики самые тупые в мире, если верить большинству комментов к некоторым статьям.

[ip1981]

отправлять свой код в эксплуатацию (прим. пер.: в продакшн);

В цитатник! :)

[yarmik3d]

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

[alex-khv]

Да нет же. Просто все эти рекомендации общие. И пришли в мир gjango из других языков. Это как написать статью, что мы в Apple, сделали революционные виджеты на рабочем столе. Хотя это давно применяется в Android.

[yarmik3d]

Django не язык, а фреймворк, и если говорить откуда что пришло то из Django много что перешло в другие фреймворки на пхп.

[Elemir]

Мастерство заголовка! Нет бы написать 1000rps