hydra_13

Кучи - это древовидные структуры, которые следуют свойствам кучи: каждый узел больше или равен своим потомкам, при этом для сравнения используется внедренный метод сравнения, который является общим для всей кучи.

т.е. добавляем элементы в кучу в разном порядке, а в итоге формируется та самая увеличивающаяся "куча"

1
         |
+-----+--+--+-----+
|     |     |     |
2     3     4     5
|     |           |
+   +-+-+         +
|   |   |         |
7   6   8         9
                  |
                +-+-+
                |   |
               10   11

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.

Есть такие штуки, книги называются, раньше говорят было модно.

затем же зачем в erlang нужны микропотоки и в golang горутины.

Ты в дверь шириной 80 см пытаешься затолкать объект шириной 100 см. Как думаешь, у тебя получится? :)

Будут работать на максимально поддерживаемой частоте материнской платы\процессора

Если хочется просто и быстро, то вполне сгодится Apache Benchmark идущий в комплекте с веб-сервером Apache. Как-то так:

ab -n 1000 -c 10 http://my.site.dot.com/url/path/

Варьируя число одновременных соединений (-c 10) и общее количество запросов (-n 1000) можно примерно прикинуть когда сайт начнёт загибаться. Тестировать лучше с другой машины. Также стоит учесть, что если контент страницы меняется от запроса к запросу (динамика), то AB посчитает такие ответы сервера как Failed: www.celebrazio.net/tech/unix/apache_bench.html

Начать тестирование лучше с наиболее часто посещаемых страниц исходя из аналитики сайта, а также ориентируясь на своё понимание его структуры (если сайт самописный, то вы должны прекрасно представлять его слабые в плане производительности разделы).

Если захочется большего — смотрите более богатые по возможностям Apache JMeter или Tsung (первый графический, второй консольный). Оба умеют кластеризоваться и генерировать нагрузку с нескольких машин (для этого удобно арендовать инстансы в Amazon EC2), имеют встроенный прокси для записи пользовательских сессий и позволяют задать скорость клиентского соединения (актуально для имитации медленных клиентов и оценки влияния того же nginx). UPD: ещё неплох Yandex Tank

В любом случае, перед тем как измерять производительность сайта, озаботьтесь мониторингом серверов на которых этот сайт крутится. Без этого смысла в бенчмарках очень мало — они дадут вам какие-то цифры, но дальнейшего плана действий у вас не будет. Как минимум — запустите на машинах утилиту top и смотрите загрузку CPU, потребление памяти и дисковую активность. Также после тестирования просматривайте логи на предмет появившихся ошибок (нехватку сокетов, памяти, ошибки веб-сервера или БД). Полезно включить логгирование медленных запросов в MySQL.

Дальше — устраняйте выявленные узкие места и повторяйте процесс заново, до тех пор пока не выйдете на приемлемый уровень производительности.

19.654s systemd-journal-flush.service
20 сек это дофига, скроее всего у вас сильно разросся(может занимать до 4 гигабайт) файл журнала
как вариант удалить и задать приемлемый лимит
ну а далее разбираете по порядку и степени нужности, UFW это файрвол, если доверяете своей локальной сети и сидите за роутером то в принципе можно безболезненно отключить или как вариант отложить его загрузку, ну и так далее

NP
Выберите JS и тэг массивы+функционалку

Шардинг - это "инструмент" не для новичков, наверно поэтому в монге дан низкоуровневый подход к построению архитектуры с расчетом на падение нод и т.п., что будет с еластиком если одина из 4-х нод умрет?
В любом случае можно сделать скрипт (или взять готовый где-то) где по "одному клику" будет шардинг собираться и расширяться.

Полнотекстовый поиск сравнивать тут конечно смысла нет.
А вот если мы рассматриваем Монгу и ЭластикСерч как БД, то вставка записей в монгу происходит гораздо быстрее.
И монговский шел гораздо удобнее чем курлом JSON-ы отправлять. Есть еще такая прикольная штука как bulk operations.
Эластик в качестве БД люди используют, но синтаксис для таких целей кажется монструозным.
Еще монга schemaless, в эластике надо указывать mappings.

Дальше еще возникает проблема с отдачей плейлиста .m3u8 файла, так как в него вносятся новые .ts файлы он должен отдаваться непосредственно из стрим сервера, то его нельзя кешировать

m3u8 кешировать можно.
Мастер плейлист можно закешировать, например, на минуту - количество вариантов(качеств) не меняется часто.
Плейлист с ts(чанклист) можно закешировать на длинну чанка - если чанки 10 секунд, то спокойно кешируй их на 10 секунд.

Можно перед nginx с ртмп модулем поставить кеширующий фронт(с включенным cache_lock), кеш на рамдиск, чанки кешировать, время кеширования зависит от размера чанклиста.

Почему параметр hls_fragment выбран 2 и 3 секунды?
Советую сделать 5.

Как реализовано вот это?

А на клиенте уже рандомно обращаемся к одному из кеш серверу

В целом вполне рабочая схема для http стриминга это:
пакетайзер(с твоём случае nginx-rtmp)
2 сервера origin-shield - для отказоустойчивости и защитить пакетайзер от большого количества запросов
N серверов edge
Мы у себя с одного эжда 10гигабит раздаём(дальше канала не хватает)...
Максимум получалось что выжать с них - 40гигабит, но это только внутри своей сети, наружу таких каналов нет.

— Ненавижу лапшу из колбеков. Не представляю как можно писать что-либо серьезное на JS не используя Фреймворки, которые хоть как-то имитируют синхронность. На худой конец jQuery. Если node.js близок к нативному JS, будет сложнее. Либо придется искать фреймворк для него.

Чтобы не было лапши из колбеков, в простых случаях достаточно просто использовать именованные, а не анонимные колбеки. В сложных случаях — async. Node.js близок к нативному JS. Но на всякий случай есть 30000 пакетов в npm.

+ Возможно, в серверной части будет не так много асинхронных задач, как во фронтэнде и не будет такой лапши из колбеков.

Если у вас будет много синхронных задач, то Node.js не лучший выбор.

— ПХП нравится за кучу встроенных функций (работы с массивами, строками, БД, обработкой картинок и т.д.). Если в ноде в
функционал уровня ES4 и тупо нет библиотеки, чтобы ужать картинку на сервере не будет ли это слишком плачевным?

В ноде нет ничего. В npm есть все. ES5.

— Так ли страшен черт как его малюют. Понятно зачем нужна асинхронность на клиенте. Но на сервере? Только БД и связь с другими серверами (если такое встречается в реальной жизни). Может быть есть способы оптимизировать это и без асинхронности? Может быть ПХПшники через пол года придумают?

А что еще, собственно, делает бэкэнд веб-приложения? Число пи до миллиардного знака расчитывает?

Вывод — все в порядке, используете node.js.