Спасибо за комментарий, действительно на текущий момент вообще никакой работы над реальным горизонтальным масштабированием не ведется, но стоит добавить два момента:
Не отрицают, что может быть в будущем дойдут до этого руки (см. коммент на github)
Про откат миграций действительно вопрос дискуссионный, не каждую миграцию можно откатить и тд. Но так скажем новым адептам призмы будет не лишним знать такой нюанс, особенно если они пришли с опытом инструментов, где такое так или иначе присутствует.
За squash отдельное спасибо, внесу обновление в статью.
Я очень рекомендую почитать блог Вячеслава Егорова — mrale.ph всем, кто интересуется данной темой. Освещена тема внутреннего устройства V8 движка, производительности и написания правильных бенчмарков. Может mraleph тоже сюда заглянет.
А в чем связь зон и отсутствие dirty checking-а? Зоны — это же просто прозрачная замена для всяких $timeout, $interval и тд. А то, что теперь есть change detector однонаправленный, это как бы про другое.
Интересный опыт. Не понял только зачем гонять картинки и sitemap.xml через node.js. У вас же наверняка наружу смотрит nginx, который может это делать лучше и с помощью конфигурации, без лишних строк кода.
Смотрю на список инструментов и вспоминаю былое. Неужели пробовали webpack и не понравилось? Лично я ни на require.js, ни на browserify возвращаться не хочу)
От вашего комментария разит капсом.
Если говорить в теории, то в общем случае интерпретатор медленнее, чем интерпретатор + JIT. С этим как бы ничего поделать нельзя. Хочется быстрый питон — берите PyPy, они с Node.js одного поля ягоды. А так по запросу «python vs node.js performance» в гугле можно найти множество сравнений. Хотя бы раз, два первые попавшиеся.
Но я не говорю, что нода идеальный инструмент — в ней свой набор проблем.
Как только вы начнете писать бизнес логику на обычном питоне, интерпретатор питона уничтожит весь выигрыш в скорости. Я это к тому, что на голом сетевом тесте возможно python + uvloop быстрее, чем node.js, но как только появится немного дополнительного код по обработке запроса и/или подготовке ответа, node.js (не говоря, кстати, уже о go lang) будут заметно превосходить питон.
А как сейчас можно отказаться от Babel, если нужна минификация для продакшена? Я недавно думал отключить Babel на одном проекте, но потом понял, что Uglifyjs не поддерживает нормально ES6, и оставил все, как есть.
Согласись, что если бы существовала одна единственная реализация js — то разработчикам жилось бы пусть менее весло, но значительно проще. Возможно, язык бы не так стремительно развивался, но это уже немного из другой области вопрос =)
Кстати, реально редко использую Array.from, совсем про него позабыл. Спасибо, что напомнил)
А насчет V8. Забывать про других не стоит, но все чаще возникают ситуации, когда js и его реализация в V8 начинают быть не отделимы (по крайней мере сейчас): V8 самостоятельно используется в большом количестве различных проектов, Node.js, Electron, NW.js, и, конечно, Chrome OS, Extensions and Apps — это целый мир =)
Wat? Тильда — побитовая операция, она приводит операнд к 32 битному целому числу, и уже потом инвертирует биты. Так что используйте тильду только тогда, когда вы точно знаете, что вы делаете.
Slice и arguments — это очень плохие соседи с точки зрения V8. Для того, чтобы ваш код был оптимизирован, с arguments можно делать ровно 3 действия (см. @jsunderhood от Вячеслава Егорова):
arguments[i] — взятие аргумента по индексу
arguments.length
f.apply(x, arguments), где f.apply === Function.prototype.apply
Так что это, к сожалению, распространенный антипаттерн. А самое производительное решение с точки зрение V8 — копировать из arguments в новый массив в ручную, вот таким образом:
var args = new Array(arguments.length);
for (var i = 0; i < args.length; ++i) {
args[i] = arguments[i];
}
Спасибо за комментарий, действительно на текущий момент вообще никакой работы над реальным горизонтальным масштабированием не ведется, но стоит добавить два момента:
Не отрицают, что может быть в будущем дойдут до этого руки (см. коммент на github)
Уже сейчас для миграции с Redis Cluster доступна эмуляция через
--cluster_mode=emulated(https://www.dragonflydb.io/docs/managing-dragonfly/clustermode). Больше похоже на "костыль", но хоть такСпасибо за комментарий.
Про откат миграций действительно вопрос дискуссионный, не каждую миграцию можно откатить и тд. Но так скажем новым адептам призмы будет не лишним знать такой нюанс, особенно если они пришли с опытом инструментов, где такое так или иначе присутствует.
За squash отдельное спасибо, внесу обновление в статью.
Спасибо за обзор, жаль, что поздно на него наткнулся.
Могу добавить, что для пользователей Ansible будет удобно использовать готовые модули по swarm и docker в целом https://docs.ansible.com/ansible/latest/collections/community/docker/docker_swarm_module.html
Если говорить в теории, то в общем случае интерпретатор медленнее, чем интерпретатор + JIT. С этим как бы ничего поделать нельзя. Хочется быстрый питон — берите PyPy, они с Node.js одного поля ягоды. А так по запросу «python vs node.js performance» в гугле можно найти множество сравнений. Хотя бы раз, два первые попавшиеся.
Но я не говорю, что нода идеальный инструмент — в ней свой набор проблем.
А насчет V8. Забывать про других не стоит, но все чаще возникают ситуации, когда js и его реализация в V8 начинают быть не отделимы (по крайней мере сейчас): V8 самостоятельно используется в большом количестве различных проектов, Node.js, Electron, NW.js, и, конечно, Chrome OS, Extensions and Apps — это целый мир =)
Про for-in по массиву уже писали выше — просто не делайте так никогда.
Math.floor и ~~ — это не одно и тоже. Простой пример:
Wat? Тильда — побитовая операция, она приводит операнд к 32 битному целому числу, и уже потом инвертирует биты. Так что используйте тильду только тогда, когда вы точно знаете, что вы делаете.
Slice и arguments — это очень плохие соседи с точки зрения V8. Для того, чтобы ваш код был оптимизирован, с arguments можно делать ровно 3 действия (см. @jsunderhood от Вячеслава Егорова):
Так что это, к сожалению, распространенный антипаттерн. А самое производительное решение с точки зрение V8 — копировать из arguments в новый массив в ручную, вот таким образом: