Серверная оптимизация *

Работа с утечками памяти

Не так давно, в процессе разработки приложения, я столкнулся с ситуацией: на первый взгляд код был хорошо написан, однако, на этапе тестирования стали заметны зависания. Во время использования приложения и многочисленных переходов по разным экранам, производительность заметно ухудшалась с каждым разом. При анализе ситуации стало очевидно, что есть проблемы с оптимизацией. В данной статье я расскажу об основных шагах по оптимизации android приложений.

Одна из самых распространенных проблем оптимизации, с которой сталкиваются разработчики Android, это утечки памяти. Утечка памяти в Android-приложениях происходит, когда объекты, которые больше не используются, по какой-то причине не удаляются сборщиком мусора и продолжают занимать память. Это может привести к избыточному потреблению ресурсов и снижению производительности приложения.

Leak Canary

Leak Canary — это открытая библиотека для Android, которая помогает обнаруживать утечки памяти в вашем приложении. Как только утечка обнаружена, Leak Canary предоставляет уведомление с отчетом, который помогает разработчикам быстро найти и устранить причину утечки. Вся суть работы Leak Canary заключается в следующем: при добавлении зависимости в проект, в процессе его сборки интегрируется отдельный модуль. Этот модуль отслеживает жизненный цикл ссылок основных компонентов Android (и не только). Основная цель этого инструмента — обнаруживать утечки памяти, связанные с долгоживущими объектами, такими как активности, фрагменты и другие компоненты Android, которые не были корректно очищены.

Мгновенность процессов стала золотым стандартом. Пользователи требуют мгновенных результатов, и телеграм-боты не являются исключением. Без кеширования данных, боты могут столкнуться с серьезными задержками при обработке запросов. Кеш-слои в теботах - это ключевой инструмент, который позволяет значительно ускорить обработку запросов, сохраняя часто запрашиваемые данные в памяти для быстрого доступа.

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

Redis - это молниеносная, высокопроизводительная система управления данными в памяти, которая идеально подходит для кеширования в телеграм-ботах. Эта in-memory база данных спроектирована с учетом скорости и эффективности, позволяя разработчикам хранить и получать данные практически мгновенно. С Redis, вы можете сохранять разнообразные данные, такие как текстовые ответы, изображения, аудиофайлы, и даже более сложные структуры данных, все это с невероятной скоростью доступа.

Redis также предоставляет богатый набор функций, включая поддержку транзакций, публикации/подписки, управление исключениями и автоматическое удаление данных, что делает его превосходным выбором для создания надежного и масштабируемого кеш-слоя.

История о том, как время ответа сервиса выросло в несколько раз в течение месяца, в чем была причина, и какое в итоге нашли решение.

Доброго времени суток уважаемый читатель. Хотелось бы немного поговорить об оптимизации наших с вам любимых WEB приложений, написанных на нашем горячо любимом и всеми уважаемом фреймворке Django. В частности речь в этой статье пойдёт об оптимизации изображений. А теперь по порядку.

Технологический прогресс не остановить, а вместе с ним и рост требований к мощности рабочих станций, на которых выполняется разработка современных информационных продуктов. Искусственный интеллект, 3D-видео и дополненная реальность — вот лишь часть задач, которые не просто требуют серьёзных вычислительных мощностей, а буквально с радостью поглощают каждую возможность выполнить работу быстрее. 

Отвечая на запросы требовательных пользователей, компания Altos выпустила рабочую станцию Altos BrainSphere P150 F8, которая объединяет в себе высочайшую производительность и передовые технологии. В этом посте мы поговорим о том, какие компоненты этой станции обеспечивают качественное выполнение задач, требующих мощных графических вычислений.

Рассказываем, как мы пережили внезапный кратный рост нагрузки на наш сервис для автоматической загрузки объявлений. Нам пришлось искать проблемные места в архитектуре и менять её практически полностью. Весь наш путь — в этой статье.

Серверные компоненты React – это большой кусок работы. Недавно мы переосмыслили нашу документацию и устроили ребрендинг Mux. Пока мы этим занимались, мы перенесли весь материал сайтов mux.com и docs.mux.com на серверные компоненты. Так что, поверьте мне… я знаю. Знаю, что это возможно, не так страшно и, в принципе, что дело того стоит.

Давайте я вам объясню, почему, ответив на следующие вопросы: почему так важны серверные компоненты, а также для чего они хороши? Для чего они не так хороши? Как их использовать, как их постепенно внедрять и какие продвинутые паттерны следует использовать, чтобы всем этим управлять? Дочитав эту статью, вы станете замечательно представлять, следует ли вам использовать серверные компоненты React, а если следует – то как использовать их эффективно.

Сколько родилось отличных проектов open source, потому что у кого‑то руки чесались что‑то попробовать! Именно так было и в случае с Firecracker. В 2014 году компания Amazon запустила AWS Lambda, которую позиционировала как «бессерверную» вычислительную платформу. В AWS Lambda пользователь может задать функцию — скажем, десять строк кода на Python — а Lambda в ответ достроит всю требуемую инфраструктуру, чтобы сработала цепочка: прибывает HTTP‑запрос, вызывается функция, запрос обрабатывается, и, наконец, генерируется ответ.

Чтобы этот сервис работал безопасно и эффективно, Amazon нужно было разработать механизм, который позволял бы с минимальными издержками запускать виртуальные машины. Так появился Firecracker. Это монитор виртуальных машин (VMM), работающий совместно с Linux KVM. Он запросто создаёт «микро-VM» и управляет ими.

По мере расширения функциональности сервиса и роста его аудитории мы неизбежно сталкиваемся с узкими местами в производительности. Прежде чем масштабировать ресурсы для эксплуатации, следует понять, насколько эффективно эксплуатируется текущая конфигурация.

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

Как определить, что утилизация ресурсов кэширования происходит оптимально? Что если довольно большая часть нагрузки не приносит реальной пользы, и от нее с легкостью можно избавиться, тем самым разгрузив хранилище? В рамках этой статьи мы оценим эффективность кэширования бэкeнда ЛК МегаФон и расскажем о результатах проведенных мероприятий для оптимизации.

Рассказываем о процессе настройки сбора метрик серверов Supermicro с помощью утилиты IPMItool и Prometheus. 

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

У нас возникла необходимость внедрения централизованного механизма опроса IPMI/iDRAC/TP-IPMI для обнаружения перегрева, проблем с системой охлаждения и т. д. и повышения качества предоставляемого оборудования в целом. Проще говоря, мы планируем внедрить систему опроса датчиков с портов управления материнских плат, чтобы оперативно обнаруживать перегрев, неработающие или частично работающие вентиляторы и другие проблемы с охлаждением (например, проверять обороты кулеров или физическое наличие вентилятора в разъеме).

Это история о том, как мы сократили расходы на AWS на 80% всего за две недели.

Для разработчиков AWS — это Клондайк возможностей

Начнем с того, что с 2018 года мы полностью перешли на AWS для всех наших проектов, и это действительно стало настоящим спасением. Наша команда полностью удаленная, поэтому владение собственным датацентром в какой-либо точке мира вызывало бы немало сложностей. Гораздо проще и экономичнее арендовать ресурсы у AWS, избегая при этом крупных капиталовложений.

1. Введенние.
2. Zval.
3. Циклические ссылки.
4. Сборщик мусора.
5. Алгоритм работы сборщика мусора.
6. Смотрим глазами.
7. Слабые ссылки.
8. Бонус-трэк: WeakMap.
9. Заключение.

Облачные сервисы — это отлично, но, если ими начинают пользоваться разные команды в компании, вопрос управления затратами превращается в «черный ящик». Когда мы только начинали нашу историю с FinOps, то даже не представляли, насколько эффективнее можно раскрутить историю с арендой облачных мощностей. Но оказалось, что расширение практик управления затратами помогает получить от облаков еще больше отдачи и не допустить необдуманных трат (а то один стартап решил как-то вечером расшифровывать ДНК на арендованных мощностях, а утром закрыл компанию, потому что потратил все деньги). О том, как это было, какие грабли мы собрали по пути, как нам помогла команда ИБ и за счет чего мы теперь экономим до 20% на облачных счетах, читайте под катом.

1. Общие сведения.
2. Увеличиваем потребление памяти вдвое.
3. Увеличиваем потребление памяти втрое.
4. Ещё раз увеличиваем потребление памяти на ровном месте.
5. Заключение.

Что описывается: Apollo-client — популярная библиотека для работы с GraphQL. Библиотека призвана ускорить разработку и оптимизировать приложение.

Задача статьи: Описать возможные решения и проблемы оптимизации приложения в части apollo-client.