Обратный прокси‑сервер также может обрабатывать прекращение SSL и TLS, и вы можете проверять зашифрованный трафик, чтобы принимать более обоснованные решения по балансировке нагрузки.
Это у вас перевод такой? Источник не хотите указать?
задержки/Delay/Sleep это все таки костыли. Неочевидные и не понятные. Я вот такие прокси (mongos/haproxy/envoy) добавляю как sidecar контейнер к поду. Заодно исчезает проблема дополнительной задержки, когда приложение и прокси находятся на разных нодах.
Какие-то у вас решения из разряда битв с ветряными мельницами.
1. Если вам так хочется самим рулить версиями пакетов — возьмите gentoo|arch, будут вам на выбор gcc от 6.5 до 11.0 и без танцев с бубном. Все патчи предоставит дистрибутив.
2. Ну или по современному — делайте сброку в докер контейнере. Благо у gcc есть официальные образы с версиями от 8 и выше. Тогда сменить версию можно будет поменяв пару цифр в пайплайне сборки приложения.
Решение с ingress и hostNetwork интересное, но deployment. Что будет если gw-2 на долго улетит в ребут или еще чего и второй под воскреснет на gw-1? Может быть лучше daemonset?
Половина пользователей с большой скоростью это iOS.
Безлимитные тарифы
LTE по спекам сделан для возможности комерческих безлимитов. Делается это за счет приоритизации траффика. т.е. чем больше вы качаете — тем меньше у вас приоритет. Это не особо приятно.
Работал когда-то на сервисе показа фильмов. С видео трафиком 100Гбит/с
Режут качество видео — чтобы клиенты не потратил месячную норму на один фильм. Поэтому редки фильмы с большим битрейтом. LTE это быстро, но тарифы некто не отменял.
Многие клиенты — мобильные и планшеты. Кеширование на диск не удачно — у них всего гигов по 30 пямяти, а бывает и сильно меньше. Про телевизоры вообще молчу.
Режут максимальную скорость до 2*битрейт — чтобы человек не тратил трафик зря. Часто смотрят 10 минут начала из 100 минут фильма, а потом смотрят другой фильм/серию.
P2P раздача видеопотока работает хорошо на трансляциях, и первый день на новинках. В остальных случаях опирайтейсь только на свои сервера.
1. Бекапить снапшотами файловой системы. lvm|zfs вам в помощь.
2. Логи читать. Следить за версиями mongo|mongos.
3. Глянуть в мониторинг, в текущие запросы. В слоу лог.
4. Работа с нодами отлично описана в офф документации.
5. А что мигрировать? Схемы нет. Данные — валидируйте и обновляйте на уровне своего приложения.
Ясно. Пропустил момент что вы чистите по расписанию, а не после сборки. А у вас места хватает тогда? У нас за рабочий день может быть до 100 сборок (тестируем каждый новый пуш коммитов во всех ветках). Если волумы не удалять сразу — за день гигов 100 мусора. И это с ограничением в 4 раннера.
Я возможно не верно понял Makefile, но у вас в остановке контейнеров и их чистке нет фильтрации по CI_JOB_ID. т.е убиваются контейнеры из параллельных пайпов, которые возможно еще работают?
1. Полностью согласен. Очень удобно для timeseries
2. Вы чуть лукавите. В Кликхаусе NULL при инсерте не обязательны. Но вручную поддерживать схему нужно и это очень муторно. Автоматические ALTER TABLE что бы добавить столбец или изменить индекс (((( — в инфлюксе схема очень гибкая.
Лично мое мнение influxdb — не production-ready для важных данных. Уже больше года использую как хранилище точек мониторинга. В нем только те данные которые можно потерять без особых проблем.
Вывод у вас полностью верный.
От себя могу добавить — при работе с любой tsdb забудьте про запросы SELECT * FROM. Всегда используйте агрегирующие функции. Если вам нужны все данные по всем точкам с сортировкой не по времени — то вам не tsdb.
Еще лучше всегда указывать нужный промежуток времени в запросе — у инфлюкса ряды партиционируются по времени.
Ну почему не разрешает? Большая куча видео контента в 10-битном цвете на трекерах говорит что разница вполне возможна и очевидна.
А вот что там и где заметно — это уже не по теме сабжа и вообще холивар. Тема — настройка монитора чтобы работал полноценно, а не как получится.
Это у вас перевод такой? Источник не хотите указать?
Из того что с чем я сам бился и устал.
Однопоточная работа индексов. Можно как-то решать через Distributed, но real-time индексам это не помогает.
Баги фиксились годами. И это при наличии открытого кода и пулл реквестов на гитхабе.
Где там у исходный код теперь у сфинкса? Что с лицензией? Распространяется бинарными пакетами. Серьезно?
И последнее, но самое вкусное - репликация. real-time индексы без репликации и минимального HA - это кусочек нестабильности вашего сайта.
Я думал все живые пользователи sphinx уже перешли на manticoresearch Вы его не рассматривали?
1. Если вам так хочется самим рулить версиями пакетов — возьмите gentoo|arch, будут вам на выбор gcc от 6.5 до 11.0 и без танцев с бубном. Все патчи предоставит дистрибутив.
2. Ну или по современному — делайте сброку в докер контейнере. Благо у gcc есть официальные образы с версиями от 8 и выше. Тогда сменить версию можно будет поменяв пару цифр в пайплайне сборки приложения.
Весь смысл ca-certificates.crt в том чтобы он был актуальный и регулярно обновлялся. А вы его в образ навечно. Не надо так.
LTE по спекам сделан для возможности комерческих безлимитов. Делается это за счет приоритизации траффика. т.е. чем больше вы качаете — тем меньше у вас приоритет. Это не особо приятно.
Режут качество видео — чтобы клиенты не потратил месячную норму на один фильм. Поэтому редки фильмы с большим битрейтом. LTE это быстро, но тарифы некто не отменял.
Многие клиенты — мобильные и планшеты. Кеширование на диск не удачно — у них всего гигов по 30 пямяти, а бывает и сильно меньше. Про телевизоры вообще молчу.
Режут максимальную скорость до 2*битрейт — чтобы человек не тратил трафик зря. Часто смотрят 10 минут начала из 100 минут фильма, а потом смотрят другой фильм/серию.
P2P раздача видеопотока работает хорошо на трансляциях, и первый день на новинках. В остальных случаях опирайтейсь только на свои сервера.
2. Логи читать. Следить за версиями mongo|mongos.
3. Глянуть в мониторинг, в текущие запросы. В слоу лог.
4. Работа с нодами отлично описана в офф документации.
5. А что мигрировать? Схемы нет. Данные — валидируйте и обновляйте на уровне своего приложения.
2. Вы чуть лукавите. В Кликхаусе NULL при инсерте не обязательны. Но вручную поддерживать схему нужно и это очень муторно. Автоматические ALTER TABLE что бы добавить столбец или изменить индекс (((( — в инфлюксе схема очень гибкая.
Лично мое мнение influxdb — не production-ready для важных данных. Уже больше года использую как хранилище точек мониторинга. В нем только те данные которые можно потерять без особых проблем.
От себя могу добавить — при работе с любой tsdb забудьте про запросы SELECT * FROM. Всегда используйте агрегирующие функции. Если вам нужны все данные по всем точкам с сортировкой не по времени — то вам не tsdb.
Еще лучше всегда указывать нужный промежуток времени в запросе — у инфлюкса ряды партиционируются по времени.
А вот что там и где заметно — это уже не по теме сабжа и вообще холивар. Тема — настройка монитора чтобы работал полноценно, а не как получится.