[Перевод] Да, Python медленный, но меня это не волнует
Комментарии (22)
2 июня 2017 в 08:53
0↑
↓
Скорость это не только скорость, но и максимальная нагрузка на сервис. 30 rps или 6000rps с ноды. А значит меньше серверов, меньше поддержки, меньше трат и немаловажная фича, которую бизнес хорошо понимает: возможность расширяться в N раз, не сталкиваясь с поблемами со стороны сервисов.
TyVik
2 июня 2017 в 09:00 (комментарий был изменён)
0↑
↓
Да, автор на это тоже обращает внимание и приходит к выводу, что дешевле будет доставить ещё один сервер, чем тратить время программиста. Ну, по крайней мере там :) Я не думаю, что это можно и нужно делать бесконечно, но гораздо проще будет провести оптимизацию комплексно в спокойное время.2 июня 2017 в 09:09
0↑
↓
Все зависит от нагрузки, 1 сервер + 1 сервер может и не пробелма, а вот если количество растет, типа 10 серверов вместо 5, или когда объемы доходят до сотен. 50 серверов или 100 серверов, есть ведь разница.А скорость разработки — это не язык, а года существования компании или года практики разработчика, у которых все уже готово и остаются только » частные случаи». Сегодня back-end совсем упростился, в компаниях на 5 front-end 1 back end, потому поднять базу данных и API для CRM — нужен 1 день, ну еще парочка на частные случае или если есть какие-то особенные вычесления, а вот на Front-end постоянно уходит огромное количество времени.
2 июня 2017 в 09:19
0↑
↓
Чем больше серверов, тем больше нужно админов, тем выше капитализация компании. Так работает бизнес, так работает экономика… Глядишь и унылый говно-чат уже проходит многомиллиардное IPO: DИменно поэтому бизнес так любит python.
Antervis
2 июня 2017 в 10:01
0↑
↓
сомневаюсь что бизнес любит капитализацию в ущерб прибыли
2 июня 2017 в 09:16
0↑
↓
Сказать «дешевле поставить еще один сервер» можно только тогда, когда мы сравним траты в обоих случаях, то есть данное утверждение надо подкрепить цифрами и показать, масштабируется ли оно, то есть справедливо ли по прежнему будет сказать «дешевле поставить еще 3000 серверов, чем иметь 200 и научить программистов один раз и навсегда писать более качественный и шустрый код». Мне не кажется, что ответ так однозначен, как преподносится в статье. Особенно с точки зрения бизнеса.
Как говорится «скорость — это тоже фича».-
TyVik
2 июня 2017 в 09:38
0↑
↓
Да, кстати, цены можно обсудить. m3.medium (1xCPU, 4Gb) стоит $350 за год, то есть ~20 000 руб. Насколько я знаю, это месяц работы джуниора (вряд ли ему кто-то доверит такую задачу) или 4 дня мидла. А у него задачи могут быть расписаны на недели вперёд.
Смотрите на это как на технический долг — да, мы сейчас ставим более дорогое железо, но в будущем эту ситуацию обязательно исправим.2 июня 2017 в 09:58
0↑
↓
А когда речь про 1000 серверов и не medium? Я про то, что обобщать по меньшей мере странно. Что может быть верно для небьльшого или среднего проекта, то оказывается фантастическими убытками на больших нагрузках, когда число тех же серверов давно идет на сотни и тысячи. Дешевле несколько заняться бизнес-процессами и устроить обучение в расках компании, заодно с нагрузочным приемочным тестированием. Как итог иметь разовые вложения в программистов против регулярных плат за впустую используемые мощности.
-
Antervis
2 июня 2017 в 09:59
0↑
↓
возникает вопрос: что дешевле — платить квалифицированному по части оптимизаций специалисту или покупать новый сервер?
2 июня 2017 в 09:39
0↑
↓
максимальная нагрузка на сервис. 30 rps или 6000rps с ноды
Представим что у вас 10 000 000 ежемесячных посетителей. То есть ваш сайт входит в US топ150 по посещаемости и находится рядом с такими ребятами как airbnb.com и steamcommunity.com Пусть каждый посетитель просматривает 10 страниц. Таким образом у вас 10000000×10/30/24/60/60 = 38 rps. Стоило оптимизировать сервис до уровня 6к?
Nerten
2 июня 2017 в 09:58
0↑
↓
Ах, если бы 1 страница это был 1 запрос.2 июня 2017 в 10:01
0↑
↓
Эх… Солидарен. Если бы одна страница == один запрос…
2 июня 2017 в 09:58
0↑
↓
Представим, что столько за приходит за час или меньше.
2 июня 2017 в 09:18
0↑
↓
Подправьте меня пожалуйста. Что если аренда сервера стоит 250$, и мы добавляем второй, вместо оптимизации, то это 500$. 6000$ каждый год, Программиста можно уволить или перевести на другой проект, а расходы останутся, а кто эти два сервера будет администрировать? Админу теперь вместо 1, надо администрировтать 2 сервера.А что буде тесли 1 сервер упадет? (Риторический вопрос)
Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10–50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история.
— Более того, я не согласен про скорость, понятие скорости очень размыто и зависит от прокладки. Такое ощущение, что каждая новая работа — это чистый лист. Потратил на 4000$ больше, зато экономишь каждый год 3000$, а это 15000$ за 5 лет
-
TyVik
2 июня 2017 в 09:31
0↑
↓
Уверен, что в компании, которая нуждается в серверах m4.2xlarge (а это 32Gb RAM и стоят они всего $2000/год), зарплаты программистов гораздо больше $4000/mo. К тому же я б разбил такой сервис на кучу маленьких серверов и засунул в autoscale группу — удобнее будет и спокойнее по ночам. Ну и ещё раз повторюсь — оптимизации никто не отменял, но это работа с высокими рисками по времени (может занять день, а может и неделю), так что лучше её проводить в спокойное время.2 июня 2017 в 09:37
0↑
↓
Уверен — не аргумент, вы так уверенно считаете чужие деньги) Проекты очень разные, даже там где есть деньги, есть автоматические скрипты, которые не требуют суппорта годами. А есть проекты, где денег мало, клиентов мало, но данных очень много.А что делать, если данные ждут сначала жесткий или SSD, а потом приходится еще и проц ждать)
2 июня 2017 в 09:47 (комментарий был изменён)
0↑
↓
Про зарплаты — это не так. Достаточно вспомнить те же зарплаты в яндексе, которые несколько ниже рыночного уровня.
В больших компаниях спокойного времени часто не бывает вовсе: всегда есть горящая кампания, выход на новый рынок, развитие нового направления, мега-важная бизнес задача. По сути просто выше планка минимального приемлимого уровня по производительности.
С aws и большими компаниями тоже неоднозначно. Не дешевое оно удовольствие в highload: когда счета переваливают за тысячи в день, и когда понимаешь, что отсутствие возможности лично решать проблемы со связью — это задержки в недели и месяцы в важных задачах, а если вот прямо сейчас идут сотни и тысячи заказов в секунду… Все приходят к своим дц в итоге. И своей поддержке. И мы возвращаемся к вопросу оптимизации издержек на железо и поддержку.
2 июня 2017 в 09:32
0↑
↓
Замерил я производительность для своей задачи.1 млн объектов в массива + легкая арифметика заняли около 30 секунд на Python и 11 секунд на php7, NodeJS и C = 9 секунд.
Убедительная прозьба не лошить на замеры, замеры сделаны аматорки, был написал 1 алгоритм на всех языках и запускались из под консоли не для точных замеров, а для быстро решения в чем массив обрабатывать.
Так вот, 20 секунд разницы против тоже простого, но более уродливого языка.
на 100 000 000 — это уже 2000 секунд, что есть 30 минут. Откуда берутся 100 млн циклы? Это когда у вас вложеные циклы. Вложеные циклы плохо? Ну, а что делать, если задача брать 1 обхект из массива, у которого например 20 полей, проверять каждое поле по определенным патеррнам и тд (безумловно много чего было придумано для уменьшенитя этих итераций, но суть остается)
2 июня 2017 в 09:45
0↑
↓
Чтобы убрать эти 30 минут, мне надо докупить еще 1 сервер за 500$, именно столько стоит текущий, мне этого делать не хочется, а я не корпоративная компания монстр с огроными бюджетами, а задача такая есть. И я не вижу разницы в скорости разработки между Python, NodeJS, php, можете объяснить где же это узкое место.На конференциях везде проталкивают Джанго, как джина с батарейками, где все есть и ничего делать не нужно.
2 июня 2017 в 09:49
0↑
↓
Бизнес-логику писать на python, а критичные числодробилки переписывать на C. Об этом и статья. Из личного опыта, за 5 лет пришлось написать два экстеншена на чистом C. И что, из-за двух мест писать весь продукт, например, на Java? И потерять на этом пару десятков человеко-лет?
Если эта числодробилка и есть весь ваш проект, то безусловно, выбираем язык под потребности. Но, мне кажется, есть много всего вокруг этого алгоритма: пользовательские интерфейсы, API и т.д. Их тоже обязательно писать на супер-быстром языке, жертвуя своей производительностью? Python как раз дает такую гибкость.
Поводом выбрать Java может быть наличие статических анализиторов кода, широкое сообщество, кол-во доступных разработчиков на рынке, особенности продукта. Но точно не скорость работы языка как такового.2 июня 2017 в 09:52
0↑
↓
Узкое место есть, просто оно дальше. В большинстве же небольших проектов оно в язык вряд ли упрется, разве что в вопрос, на каком языке лучше и шуствее код писать и поддерживать, то есть в первую очередь, читать, в том числе и новичками.
arvitaly
2 июня 2017 в 09:52
0↑
↓
Зачем сравнивать C и Python, сравнивайте современные развивающиеся языки, которые намного быстрее, а во многом и удобнее питона.
И разница в серверах (а значит и всей инфраструктуре) может быть на порядки, если задача выполняется не в 2 раза медленнее, а в 100.
