• Оптимизация сборки мусора в высоконагруженном .NET сервисе

      Ежедневно в сервисе Pyrus работают десятки тысяч сотрудников из нескольких тысяч организаций по всему миру. Отзывчивость сервиса (скорость обработки запросов) мы считаем важным конкурентным преимуществом, так как она напрямую влияет на впечатление пользователей. Ключевой метрикой для нас является «процент медленных запросов». Изучая ее поведение, мы заметили, что раз в минуту на серверах приложений возникают паузы длиной около 1000 мс. В эти промежутки сервер не отвечает и возникает очередь из нескольких десятков запросов. О поиске причин и устранении узких мест, вызванных сборкой мусора в приложении, пойдет речь в этой статье.


      Читать дальше →
    • Первый взгляд на FoundationDB, открытую Apple

        В прошлой статье мы рассматривали ограничения и препятствия, которые возникают, когда нужно горизонтально масштабировать данные и иметь гарантию ACID-свойств транзакций. В этой статье рассказываем о технологии FoundationDB и разбираемся, как она помогает преодолеть эти ограничения при разработке mission-critical приложений.

        FoundationDB — это распределенная NoSQL база данных с ACID-транзакциями уровня Serializable, хранящая отсортированные пары ключ-значение (ordered key-value store). Ключами и значениями могут быть произвольные последовательности байт. У неё нет единой точки падения — все машины кластера равноправны. Она сама распределяет данные по серверам кластера и  масштабируется на лету: когда в кластер нужно добавить ресурсов, ты просто добавляешь адрес новой машины на конфигурационных серверах и база сама подхватывает ее.
        Читать дальше →
      • Масштабирование БД в высоконагруженных системах

          На прошлом внутреннем митапе Pyrus мы говорили о современных распределенных хранилищах, а Максим Нальский, CEO и основатель Pyrus, поделился первым впечатлением от FoundationDB. В этой статье рассказываем о технических нюансах, с которыми сталкиваешься при выборе технологии для масштабирования хранения структурированных данных.

          Когда сервис недоступен пользователям какое-то время, это дико неприятно, но всё же не смертельно. А вот потерять данные клиента — абсолютно недопустимо. Поэтому любую технологию для хранения данных мы скрупулезно оцениваем по двум-трем десяткам параметров.
          Читать дальше →
        • Об особенностях архитектуры Android глазами не-Android разработчика

            Недавно мы полностью переработали приложение Pyrus для Android. Первая версия приложения работала аж под Android 2.2. Отказавшись от поддержки Android ниже 4.1, мы смогли выплатить накопленный технический долг и заметно упростили исходный код. Да, мы потеряли часть пользователей (менее 1%), но зато мы сэкономили время разработчиков на исправление редких багов. Мы сможем инвестировать его в развитие функционала для всех текущих и новых пользователей. В долгосрочной перспективе это гораздо важнее.

            Здесь мы делимся опытом, который может быть полезен тем, кто подумывает начать разработку для платформы Android.
            Читать дальше →
          • Выбор надежной БД в высоконагруженном проекте

              Привет Хабр! Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно. Наша технология хранения информации многократно доказала свою надежность. Компания развивается, и мы озаботились вопросом выбора БД на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту и при этом не менять платформу каждые 2-3 года. Конкуренция на рынке баз данных развита: представлено много решений, большая часть из них open source и/или бесплатные. Ищем «идеальное решение»™ для нашей задачи.
              Читать дальше →
            • Выбор MQ для высоконагруженного проекта

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

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

                Если микросервис перестает отвечать на запросы в результате аварии, его клиенты должны быть мгновенно перенаправлены на резервный. Для управления потоком запросов часто используют так называемые очереди сообщений (message queues).

                Недавно используемая нами очередь перестала нас устраивать по параметрам отказоустойчивости и мы заменили ее. Ниже мы делимся нашим опытом выбора.
                Читать дальше →
              • 5 уроков для разработчиков высоконагруженных систем

                С 2010 года мы разрабатываем сервис для организации совместной работы и управления процессами. Сейчас в нашей системе Pyrus работают тысячи организаций и десятки тысяч пользователей. За 4 года мы наработали неплохой опыт обеспечения надежности и хотим поделиться им с вами.
                Читать дальше →