отнюдь. да, джуниорам надо об этом напоминать, интермидам тоже иногда приходится, но в целом — все готовы поддерживать этот функционал сразу.
и они его сделают (или хотя бы попытаются), если их вовремя направить в правильное русло.
зачастую, проблемы в том, что напоминать некому, а в планы по разработке и CI это вообще изначально не входило, потому что менеджер не в курсе про CI, да и в стоимость продукта это не включено :)
как участник движения devops, могу сказать, что не было, нет и не будет никакой «серебряной пули» в этом вопросе.
у всех задач по разработке есть свой приоритет, и его нельзя нарушать без серьезных на то причин.
разумеется, со стороны operations вопросы по оптимизации должны регулярно подниматься на основе данных мониторинга и анализа.
есть поинты, которые можно относительно просто оптимизировать, не тратя не это много человекочасов, т.е. безболезненно для velocity.
попадаются задачи, которые тяжело и/или долго оптимизировать, проще «добавить железа», если это решит проблему.
хуже, когда и проблема перфоманса серьезная, и девелоперы решить ее не могут физически — с этим часто сталкиваются в big data, например — когда нельзя просто так взять и положить сотню терабайт в одну табличку.
для большинства разрабатываемых ныне софтовых продуктов первые два типа проблем встречаются наиболее часто.
учитывая последние тенденции, когда ПО работает в облаке, имеет грамотную инфраструктуру и умеет работать в кластере, гораздо проще и дешевле, что немаловажно, просто добавлять ноды в кластер, менять типы инстансов, варьируя тем самым перфоманс.
почему? а выше уже написали — hardware is cheap, programmers are expensive. это факт.
могу только дать пару советов обоим сторонам.
админам — внедрять виртуализацию и удобные инструменты для управления, если у вас этого еще нет, и не задумываться над ответом на вопрос «добавлять памяти или нет?».
программерам — всегда держать в голове вопрос «а умеет ли мое приложение работать в кластере и скейлиться горизонтально?», и если нет — вы готовите его неправильно.
работайте в команде — ищите компромисс вместе, не перекладывайте на других ответственность, делите ее со всеми.
есть маленький нюанс ко всему вышесказанному.
на t2 работают только hvm ami, и не работают pv ami.
грубо говоря, если до этого вы использовали не windows или не high-compute gpu cluster, то стопнуть и запустить свои инстансы в новом формате просто так не удастся.
молодцы, в очередной раз сравнили трудносравнимые вещи, теперь в области цен.
зачем сопоставлять чистый и понятный IaaS с вашим продуктом?
чтобы еще раз показать очевидные различия в способе ценообразования?
забудь о проблемах масштабирования и нехватки производительности
дальше, в целом, можно не читать.
master-slave репликация
haproxy балансирует запросы в режиме round-robin к MySQL
WAT
Это делает сам Nginx, он балансирует между серверами приложений на основе IP-адресов клиентов. Запрос с одного IP будет попадать всегда на один и тот же сервер. Балансировка запросов осуществляется при помощи haproxy, который необходимо было установить на каждый сервер
65 WAT
впечатление, что маркетолог писал техническую статью.
поставил минус с чистой совестью. нечем тут хвалиться, да и делиться таким опытом с другими — тоже.
download master показывает 20 МБ/сек.
руководствуясь нормами по содержанию битов в байтах получаем 160 Мбит/сек.
у вас, похоже, в байте порядка 9.5 бит.
хайлоад — понятие растяжимое.
увидите, что хендшейк с ключом на 4096 происходит раз в 50 медленнее, чем с ключом на 1024.
спасибо, улыбнуло.
перфоманс уже замеряли?
и они его сделают (или хотя бы попытаются), если их вовремя направить в правильное русло.
зачастую, проблемы в том, что напоминать некому, а в планы по разработке и CI это вообще изначально не входило, потому что менеджер не в курсе про CI, да и в стоимость продукта это не включено :)
у всех задач по разработке есть свой приоритет, и его нельзя нарушать без серьезных на то причин.
разумеется, со стороны operations вопросы по оптимизации должны регулярно подниматься на основе данных мониторинга и анализа.
есть поинты, которые можно относительно просто оптимизировать, не тратя не это много человекочасов, т.е. безболезненно для velocity.
попадаются задачи, которые тяжело и/или долго оптимизировать, проще «добавить железа», если это решит проблему.
хуже, когда и проблема перфоманса серьезная, и девелоперы решить ее не могут физически — с этим часто сталкиваются в big data, например — когда нельзя просто так взять и положить сотню терабайт в одну табличку.
для большинства разрабатываемых ныне софтовых продуктов первые два типа проблем встречаются наиболее часто.
учитывая последние тенденции, когда ПО работает в облаке, имеет грамотную инфраструктуру и умеет работать в кластере, гораздо проще и дешевле, что немаловажно, просто добавлять ноды в кластер, менять типы инстансов, варьируя тем самым перфоманс.
почему? а выше уже написали — hardware is cheap, programmers are expensive. это факт.
могу только дать пару советов обоим сторонам.
админам — внедрять виртуализацию и удобные инструменты для управления, если у вас этого еще нет, и не задумываться над ответом на вопрос «добавлять памяти или нет?».
программерам — всегда держать в голове вопрос «а умеет ли мое приложение работать в кластере и скейлиться горизонтально?», и если нет — вы готовите его неправильно.
работайте в команде — ищите компромисс вместе, не перекладывайте на других ответственность, делите ее со всеми.
на t2 работают только hvm ami, и не работают pv ami.
грубо говоря, если до этого вы использовали не windows или не high-compute gpu cluster, то стопнуть и запустить свои инстансы в новом формате просто так не удастся.
что-то отличное от признания действия законным и ненаказуемым?
зачем сопоставлять чистый и понятный IaaS с вашим продуктом?
чтобы еще раз показать очевидные различия в способе ценообразования?
чисто орфографические исправления бесполезны, имхо.
оно было в Школьном, но тамошний центр буквально практически уничтожен украиной.
not sure if trolling or just a mistake.
WAT
65 WAT
впечатление, что маркетолог писал техническую статью.
поставил минус с чистой совестью. нечем тут хвалиться, да и делиться таким опытом с другими — тоже.
руководствуясь нормами по содержанию битов в байтах получаем 160 Мбит/сек.
у вас, похоже, в байте порядка 9.5 бит.