Мне кажется вы привели слишком много примеров использования с хранением объектов в kafaka. Но это не рекомендуется для событийно ориентированных приложений.
При такой схеме каждому сервису нужно самому разбираться в изменениях объекта, а для этого их нужно сохранять (хотя бы частично) в локальной бд сервиса. Такое приводит к колоссальному дублирования данных.
Я конечно понимаю что это перевод. Но это инструкция по установке версии 7.9.4. Которая вышла в апреле 2015 года. На убунту14.04 срок поддержки которой заканчивается уже через год.
>> То есть в начале всегда читаем из старой базы, и на фоне проверяем что в новой данные тоже есть ( а если нет — дотягиваем).
А если они есть везде, но разные?
У вас новый шардинг уже в публичном доступе. Вот об этом была бы интересна статься. Почему от старого отказались? Какие вкусности будут в новом?
За ссылку спасибо!
У редиса есть шардирование из коробки. Позволяет хранить там много данных с равномерной производительностью. А у тарантула как с горизонтальным ростом?
>> Чем нам не понравилось решение на nginx- накрутить нашу логику в конфиге можно, но выглядеть это будет очень уж страшно.
Ну я не знаю что страшней. 20 строк в конфиг nginx (локейшен для ресайза и парсинг аргументов — размеров + настройки кеша и pagespeed) или отдельный демон для ресайза.
Я конечно уверен что демон гибче и потому производительней. Но его ж нужно самим поддерживать, развивать и править баги.
У нас в принципе картинки ходят через отдельный инстанс. В настройках включена только оптимизация изображений. Без кеширования его включить нельзя. У него асинхронная модель оптимизации. На первый просмотр он всегда отдает оригинал.
Удобно тем что разным клиентам отдает разные оптимизации. Кому-то webP, а кому-то оптимизированный jpeg. Ну и конечно все рекомендованные оптимизации от гугла из коробки.
Сейчас пробывал очистить кеш pagespeed. На секунд 30 nginx скушал 4 ядра процессора и создал 1 гигабайт кеша за это время. После этого нагрузка сразу упала до привычных 20-30% У нас примерно по 200rps показы картинок. Но это веб сайт — кеширование результатов ресайза очень эффективно(больше 99% из кеша берется).
Пробывали модуль для nginx — google pagespeed?
В нем есть отличный оптимизатор картинок вплоть до конвертации в WebP для современных браузеров.
Мы используем ngx_http_image_filter_module для ресайза и pagespeed для оптимизации. Нагрузка минимальна. Полученные картинки конечно кешируются в pagespeed
Мы мониторим несколько метрик. Потребления памяти конкретного процесса(RAM и своп отдельно). И свободную рам память. Последняя метрика с алертом.
Неоднозначность — приложение может в любой момент решить использовать что-то старое и перенесет это из свопа в RAM. Резко и очень много.
Отдельный такой пик мы переживаем без проблем. Но если одновременно так сделают 2-3 процесса — пик слишком большой и активные процессы свопятся и тормозят.
При этом система стабильна по производительности и имеет запас свободной памяти в 20-30%
А можите больше рассказать о сетевой подсистеме? Почему выбрали Flannel? Делали какие-то тесты скорости между нодами на разных серверах? Отличаются ли время пингов между контейнерами от пингов между серверами?
Честно говоря — вы меня не убедили. Отсутствие свопа в продакшене дает стабильную производительность приложения в любых условиях. Если какие-то страницы памяти не использовались сутки — скорость доступа будет также высока. И конечно варнинги на доступную память в мониторинге намного более просты и очевидны когда своп не используется. Я привык что если на ноде не хватает памяти — лучше что бы она выключилась(ООМ) чем тормозила.
Ручное компилирование и раскладывание библиотеки по серверам? Вы прям в 2005 год ушли.
А как же автоматизация, оркестрация и тестирование? Тут лучше бы подошел плейбук для ansible или что-то подобное, как цель этой статьи. Что бы проблем с обновлением не было.
И укажите линк на оригинал интрукции по сборке. Она ведь меняется иногда.
При такой схеме каждому сервису нужно самому разбираться в изменениях объекта, а для этого их нужно сохранять (хотя бы частично) в локальной бд сервиса. Такое приводит к колоссальному дублирования данных.
А если они есть везде, но разные?
За ссылку спасибо!
Ну я не знаю что страшней. 20 строк в конфиг nginx (локейшен для ресайза и парсинг аргументов — размеров + настройки кеша и pagespeed) или отдельный демон для ресайза.
Я конечно уверен что демон гибче и потому производительней. Но его ж нужно самим поддерживать, развивать и править баги.
Удобно тем что разным клиентам отдает разные оптимизации. Кому-то webP, а кому-то оптимизированный jpeg. Ну и конечно все рекомендованные оптимизации от гугла из коробки.
Сейчас пробывал очистить кеш pagespeed. На секунд 30 nginx скушал 4 ядра процессора и создал 1 гигабайт кеша за это время. После этого нагрузка сразу упала до привычных 20-30% У нас примерно по 200rps показы картинок. Но это веб сайт — кеширование результатов ресайза очень эффективно(больше 99% из кеша берется).
В нем есть отличный оптимизатор картинок вплоть до конвертации в WebP для современных браузеров.
Мы используем ngx_http_image_filter_module для ресайза и pagespeed для оптимизации. Нагрузка минимальна. Полученные картинки конечно кешируются в pagespeed
Неоднозначность — приложение может в любой момент решить использовать что-то старое и перенесет это из свопа в RAM. Резко и очень много.
Отдельный такой пик мы переживаем без проблем. Но если одновременно так сделают 2-3 процесса — пик слишком большой и активные процессы свопятся и тормозят.
При этом система стабильна по производительности и имеет запас свободной памяти в 20-30%
А как же автоматизация, оркестрация и тестирование? Тут лучше бы подошел плейбук для ansible или что-то подобное, как цель этой статьи. Что бы проблем с обновлением не было.
И укажите линк на оригинал интрукции по сборке. Она ведь меняется иногда.