#потребление_ресурсов — Public Fediverse posts

Кто должен считать потребление в AI-сервисе: продукт или биллинг

В тариф включено 5 млн токенов. Клиент уже использовал 4,8 млн и отправляет новый запрос на 500 тысяч. Кто должен решить, можно ли его выполнить? Ответ зависит от того, кто считает потребление. Сервис может сам вести счетчик и контролировать лимит либо передавать события в биллинг, оставляя ему учет накопленного объема. В статье разбираю распределение ответственности между продуктом и биллингом: кто фиксирует использование, кто считает потребление, кто контролирует лимиты и где рассчитывается стоимость.

https://habr.com/ru/articles/1084688/

#saas #биллинг #usagebased_billing #монетизация_проекта #потребление_ресурсов #pay_as_you_go #оплата_по_факту_использования #стартап #прием_платежей #новый_продукт

Линейки версий WordPress под микроскопом

К сожалению, мир современной веб-разработки таков, что многие вебмастеры уже давно забили на качество кода, а тяжесть их решений, построенных на не менее тяжёлых популярных движках, нивелируется мощностью серверного железа. И когда ты укрыт за спиной производительного сервера, совсем непросто увидеть тот ужас бесцельного потребления ресурсов, что порождают создатели знаменитых движков. Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7. Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения.

https://habr.com/ru/articles/1062144/

#wordpress #нагрузка_wordpress #нагрузка_на_сервер #производительность_сайта #ресурсоёмкие_приложения #избыточное_потребление #потребление_ресурсов

Профилировщик CMS-движков для вебстудий

Кто хотя бы раз работал в вебстудии над создаваемыми сайтами, знает, что используемые там универсальные движки очень даже норовистые. Чуть не уследил за правильной кастомизацией кода под требования клиента - на получи тормоза при открытии его страниц. И ведь не сразу найдёшь, где же в глубинах проекта образовался проблемный фрагмент, начавший поглощать ресурсы сайта. Для поиска таких мест были созданы разные инструменты профилирования. Этим термином называют всестороннее измерение нагрузки, оказываемой исследуемым скриптом на сервер сайта. Например, для языка PHP наиболее известными профилировщиками кода являются следующие: Blackfire, Xdebug Profiler, Tideways, XHProf/XGHui. Но что если вам важнее не разноплановый функционал популярных инструментов, сколько возможность в один щелчок побыстрее выполнить основную функцию: замерить нагрузку сразу по всем задействованным файлам CMS и понятно визуализировать результат. Для решения подобной узкой задачи я разработал очень простой бесплатный профилировщик PHP. Так сказать, студийную версию профайлера, то есть урезанную до объёма, достаточного вебмастеру при работе над проектами в студии. И делюсь этим скриптом с сообществом. Кому интересно, прошу под кат.

https://habr.com/ru/articles/1058322/

#php #профилирование #профилировщик #профайлер #профайлинг #потребление_ресурсов #расход_памяти #избыточное_потребление #потеря_времени #загрузка_страницы

Я календарь переверну — и снова 5 апреля: CPU-утилизация во имя интернационализации

Недавно наша команда столкнулась с необычным поведением системы, которая начала использовать избыточное количество CPU-ресурсов. В начале года мы запустили миграцию сервиса в новое хранилище PostgreSQL с существующего NoSQL-решения. Сервис среднестатистический, не High-Load, но занимает ключевое место в обработке бизнес-процессов, отвечает за генерацию заданий для коммуникаций с клиентами. Без проблем держит поступающие 30 RPS, ежедневно обрабатывает около миллиона джобов, хранит сотни миллионов строк данных и в среднем потребляет 125ms CPU. До отключения старой инфраструктуры оставались считаные дни, в бэклоге было несколько задач на миграцию, и мы стремились уложиться в сроки. В бэкграунде крутились джобы миграции данных в новую базу, десятки фичатоглов распределяли запросы к базам данных по репозиториям для обратной совместимости, но планы рухнули из-за неожиданного поведения системы.

https://habr.com/ru/companies/tbank/articles/1021330/

#траблшутинг #потребление_ресурсов #таймзона #профайлинг #дамп

Как в Sidec благодаря exactly-once сократили потребление ресурсов без потери производительности

Меня зовут Сергей Гребенюк, я лидер разработки Sidec ( Росреестр ). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams ( kafka docs ) и RocksDB ( github ). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) ( confluent docs ), смогли снизить требования к ресурсам в несколько раз. На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй.

https://habr.com/ru/companies/sberbank/articles/863688/

#Sidec #потребление_ресурсов #kafkastreams #kafkaconnect

Потребление ресурсов в Prometheus: кто виноват и что делать (обзор и видео доклада)

У Prometheus есть серьёзный недостаток — чрезмерное потребление ресурсов. Проблема может заключаться в недостаточном понимании инструмента и его неверном использовании. А Prometheus требует грамотного управления метриками и лейблами. В своем докладе технический директор Deckhouse Observability Platform Владимир Гурьянов выяснил, кто виноват в этом и что делать.

https://habr.com/ru/companies/flant/articles/848968/

#prometheus #tsdb #monitoring #devops #devopsconf #deckhouse #метрики #потребление_ресурсов #lables #mimirtool