Когда язык может стать узким местом?

Question

[Dr. Robert Ford]

Здравствуйте. Есть небольшой проект на питоне, разделённый на микросервисы. Максимальная планируемая нагрузка - около 70-130 rps. Потлок - 200 rps, из них окло 50 могут прилететь одновременно. Проект взаимодействует с Docker API и БД(postgresql). При какой нагрузке стоит переписывать это приложение(или отдельные его части) на Go? И стоит ли вообще это делать в будущем?

Comments

[longclaps]

Будущего ещё не существует, вот настанет оно - тогда и узнаешь.

Answer 1

[Сергей Горностаев]

Во-первых, язык влияет на производительность программистов, а не программ. Узким местом может стать платформа, в вашем случае виртуальная машина CPython. Но при разработке сетевого ПО в целом и web-приложений в частности главный тормоз - это ввод/вывод. Издержки на него на порядки превосходят издержки на интерпретацию, так что последняя практически не влияет на производительность. В то же время CPython хорошо справляется с вводом/выводом с помощью Asyncio и способен решать проблему c10k.

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

Answer 2

[dollar]

Для начала в Гугле можно набрать python vs go slant

Далее, почему Go, а не Erlang, например? Обычно выбор конкретного инструмента зависит от конкретной задачи. Так что в вопросе не лишним было бы описать (хотя бы внутри спойлера), что за проект, на что акцент и т.д., если это не секрет, конечно.

Comments

[Dr. Robert Ford]

Проект - аналог D2C, т.е. этакая централизованная панель для управления несколькими серверами.

Answer 3

[rPman]

Язык почти никогда не создает проблем со скоростью, но их создают инструменты и библиотеки, которые используют разработчики, чтобы облегчить себе жизнь.

И на php (phpreact) можно написать приложение, обрабатывающее 10к запросов в секунду на одном процессоре, а можно на nodejs (javascript) написать асинхронное приложение, которое штатным распаковщиком gzip будет тратить 99% времени на распаковку gzip а потом оставшуюся половину на копирование массива с данными (из-за чего скорость на порядок ниже php получается, реальный пример простой обработки БОЛЬШОГО количества упакованных текстовых дампов)

Если же у вас проблемы создает обработка данных, пишите критичные вещи на c++ и подключайте модулем.