Но не тогда, когда у вас пара сотен веток. А когда понадобится выяснить в рамках какого таска вносились изменения в некий участок кода, причём эти изменения полугодовой давности. Боюсь, что в этом случае отследить ветвления в network будет весьма проблематично.
Не к своему ноутбуку, а к виртуалке, на которой подняты все сервисы для разработки: php-fpm, nginx, mysql (для экспериментов), xdebug, туда же приностися конфигурация приложения (мы используем подобие etcd), и прочее. Вот эта виртуалка и управляется папетом.
А ноутбук используется в качестве тонкого клиента: phpstorm, браузер и ssh-клиент.
UPD. Уточню: виртуалка находится не на ноутбуке, а на девелоперском сервере.
Мы у себя в проекте (используем Jira) пишем комментарии к коммитам так: "-: "
За 5 лет ни раз не испытывали неудоств и даже это многократно помогало, например, когда нужно было по blame скрипта определить каким коммитом вносились изменения в конкретные строки и по тайтлу коммита было легко определить из какого таска эти изменения пришли.
601 посетитель — это мелочи. Можно сказать, что трафа совсем и не было.
Для сравнения: top.mail.ru/visits?id=152591 — проект «недвижимость» у мейлрушечки, написан на PHP с использование фрейворка (не собственного, а «нормального»), 100--200 тысяч визитов в сутки, а хитов от полумиллиона. И это не самый нагруженный сайт.
(з.ы. я не работаю в этом проекте)
Попробуйте, всё-таки, потестировать ab'шкой? Если ваш сайт выдержит хотя бы 1050 хитов за полчаса (50 тысяч в сутки) с конкурентностью не менее пяти, то признаю, что ваше решение годное.
Добавлю:
Мы тоже используем ELK, тоже ES для хранения логов развернули на 3-х серверах. Но решили, использовать 3 мастер-шарда (по одному на каждую ноду) и одну реплику, подумав, что в случае вылета узла, recover индексов займёт меньше времени за счёт меньшего размера шардов.
Спасибо за интересную статью!
Отнють. Просто поинтересовался этим моментом. Извините, если тон комментария показался резким.
При шардинге в ES поиск (и фильтрация) осуществляется параллельно на всех шардах, поэтому, потенциально можно получить профит в скорости, но при этом возрастёт нагрузка на узлы. Возможно использование роутинга запросов, при котором запрос отправляется лишь на определённый шард и не затрагивает другие. Но необходимо отталкиваться от специфики хранимых данных и задач их обработки.
Поэтому уверен, что вы всё сделали правильно.
Меня смущает строка «Мы выделили три сервера для кластера Elastic Search и настроили его так, чтобы каждый индекс имел одну реплику...»
Вы реплицируете индекс целиком? Один шард на индекс?
А ноутбук используется в качестве тонкого клиента: phpstorm, браузер и ssh-клиент.
UPD. Уточню: виртуалка находится не на ноутбуке, а на девелоперском сервере.
<task_id> : <commit_title>"За 5 лет ни раз не испытывали неудоств и даже это многократно помогало, например, когда нужно было по blame скрипта определить каким коммитом вносились изменения в конкретные строки и по тайтлу коммита было легко определить из какого таска эти изменения пришли.
Для сравнения: top.mail.ru/visits?id=152591 — проект «недвижимость» у мейлрушечки, написан на PHP с использование фрейворка (не собственного, а «нормального»), 100--200 тысяч визитов в сутки, а хитов от полумиллиона. И это не самый нагруженный сайт.
(з.ы. я не работаю в этом проекте)
Попробуйте, всё-таки, потестировать ab'шкой? Если ваш сайт выдержит хотя бы 1050 хитов за полчаса (50 тысяч в сутки) с конкурентностью не менее пяти, то признаю, что ваше решение годное.
Мы тоже используем ELK, тоже ES для хранения логов развернули на 3-х серверах. Но решили, использовать 3 мастер-шарда (по одному на каждую ноду) и одну реплику, подумав, что в случае вылета узла, recover индексов займёт меньше времени за счёт меньшего размера шардов.
Спасибо за интересную статью!
При шардинге в ES поиск (и фильтрация) осуществляется параллельно на всех шардах, поэтому, потенциально можно получить профит в скорости, но при этом возрастёт нагрузка на узлы. Возможно использование роутинга запросов, при котором запрос отправляется лишь на определённый шард и не затрагивает другие. Но необходимо отталкиваться от специфики хранимых данных и задач их обработки.
Поэтому уверен, что вы всё сделали правильно.
Вы реплицируете индекс целиком? Один шард на индекс?