Комментарии 21
Статья просто жуть.
Итоговый вывод: Всегда слабое место это БД. По этому оптимизируйте запросы.
Используйте подход Microsoft — не бывает тормозных приложений. Бывает мало вычислительных ресурсов… В помощь всякие докеры и тд. Чтобы быстро решить проблему тормозов приложения. Ведь это фреймворк и в нем скорее всего нельзя в тонкую настройку sql с хинтами и прочими плюшками.
Если оптимизироват запросы, решить проблемы кэширования и разбить на микромервисы с масштабировпнием становится очевидно, что писать можно хоть черта лысого на бейсике.
Ни у одного интерпретатора не будет преимуществ.
"Как Django может обрабатывать 100 миллионов запросов в день"
Извиняюсь я из лагеря .net, а что джанго из коробки не может обработать такое ничтожное кол-во запросов? )
1200 RPS, может, да. Не на всяких там сложных бизнес-процессах, но может, даже на одном сервере.
Статью надо было назвать "как Django может обрабатывать более 3.65 млрд запросов за 10 лет"
В итоге, со слов автора. Благодаря архитектуре и инфраструктуре, позволяющей динамически масштабировать product name, можно создавать код на чём угодно. Только причём тут заслуга Django ?
Но предназначение этой статьи остается загадкой.
Зашёл поругать бесполезную, шаблонную статью, а тут уже все до меня сказали.
Как 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»}`, а другой со всеми возможными и непустыми свойствами объекта, получи массив струганины, экономя на спичках выносим мозг и глаз разрабам которые работают с этим апи.
ОЙ, короче…
отправлять свой код в эксплуатацию (прим. пер.: в продакшн);
В цитатник! :)
Мастерство заголовка! Нет бы написать 1000rps
Как Django может обрабатывать 100 миллионов запросов в день