Аппаратное Обеспечение Или Оптимизация? Badoo, Авито И Мамба — О Производительности Php

Проблема производительности PHP-кода для Badoo — одна из самых важных.

Качество PHP-бэкенда напрямую определяет количество ресурсов, которые мы тратим на разработку и эксплуатацию, скорость работы сервиса и впечатление, которое он производит на пользователей.

Поэтому мы сделали производительность бэкенда темой третьей встречи сообщества PHP-разработчиков в нашем офисе и пригласили к обсуждению коллег с Авито и Мамбы.

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

И 15 февраля приходите в следующая встреча PHP на Badoo : Давайте обсудим наследие.

Мы записали только ту часть дискуссии, которая показалась нам наиболее интересной.

Полная версия доступна на видео.

Ээксперты:

• Семен Катаев, руководитель группы разработки подразделения Core Services Avito
• Павел Мурзаков Пмурзаков , руководитель группы PHP в Badoo
• Михаил Буйлов mipxtx , ИТ-директор компании Мамба

Расскажите историю об оптимизации из вашей практики: большой успех или большой провал — чем-то, чем интересно поделиться.

Михаил Буйлов, Мамба

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

Однажды мы заметили наш контейнер зависимостей Symfony, который вырос до 52 000 строк.

Решили, что это он, подлец, во всем виноват: 20 мс оверхеда на каждый запрос.

Мы его распилили.

Мы уменьшили его.

Мы как-то пытались его отделить, но ничего не помогло.

А потом оказалось, что у нас есть антиспам, которому нужно обращаться к 20 базам данных, чтобы выполнить все необходимые запросы.

Решения, которые приходят первыми, не всегда являются правильными.

Лучше посмотреть трассировки, логи и тесты ваших запросов, а не ломать их напрямую.

Вот история.

Павел Мурзаков, Badoo

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

Мы взвешиваем аргументы за и против каждого варианта и принимаем решение.

Чаще всего — в пользу оптимизации, потому что железа нужно много.

В один из таких моментов мы выделили целую группу, которая искала разные неоптимальные вещи в PHP-скриптах и оптимизировала их.

Это происходило буквально «по капле»: нашли процент здесь, нашли процент там – несколько человек нашли процент в течение месяца.

В какой-то момент наш специалист был рядом Эйнштейн_человек .

Решил посмотреть, что можно сделать: пришел вечером, запустил Perf, нашел пару проблем в расширениях PHP — и за пару вечеров все ускорилось на 13%!

Семен Катаев, Авито

Один о провале, другой о суперразработчике.

О неудаче.

У нас есть множество микросервисов, в том числе на PHP. Все используют Kubernetes. Я работал над одним из этих микросервисов.

Была значительная загрузка процессора: мы потратили неделю на оптимизацию и поиск проблем.

Оказалось, что один из разработчиков добавил Xdebug в базовые образы для расчета тестов покрытия кода в своем (другом) сервисе, после чего все микросервисы в продакшене целый квартал работали с включенным Xdebug! Через квартал мы это обнаружили, исправили базовые образы — и начали ловить неожиданные подарки: я перекатил свой сервис, и он стал работать быстрее.

При каждом развертывании образ нашего сервиса перестраивается, и теперь без Xdebug. История успеха.

У нас много микросервисов, и их становится все больше.

В этой ситуации количество вызовов RPC становится проблемой.

Например, на карточке объявления — а это одна из самых часто используемых страниц в Авито — для рендеринга страницы используется около 30 микросервисов.

Причём всё это делается не очень явно: такое ощущение, что вы вызываете какую-то абстракцию, а под ней последовательно выполняются пять RPC-вызовов к другим сервисам.

С годами рекламная карточка сильно ухудшилась.

Один сильный разработчик целый квартал боролся, оптимизировал и вынес все вызовы RPC наружу.

Когда ему удалось это сделать, он распараллелил их через мультизапрос Guzzle — и вместо 30 последовательных синхронных запросов получил те же 30 запросов, но параллельных, что значительно ускорило работу.

После данного рефакторинга время ответа карты равно максимальному времени ответа любого из сервисов.

Но ему потребовался целый квартал, чтобы оптимизировать/переписать код отображения рекламных карточек.

Расскажите, какой размер у вас PHP-кластера, как он настроен — хотя бы PHP-FPM или, может быть, где-то подмешан Apache?

Михаил Буйлов, Мамба

В пиковое, прайм-тайм там загружено около десяти человек.

Среднее время отклика — 100 мс, и мы стараемся его поддерживать (когда оно превышает 100 мс, мы начинаем искать медленные вещи).

У нас есть собственная система контроля эффективности.

Мы раскидали по коду много счетчиков, около 120 на запрос.

Мы отслеживаем множество событий, происходящих внутри PHP-кода.

Павел Мурзаков, Badoo

Есть две особенности конфигурации.

Во-первых, у нас есть прокси BMA — это прокси для мобильных устройств.

То есть, прежде чем запрос поступит в nginx, он попадает на специальный прокси, который держит постоянное соединение и отправляет запросы в nginx. Вторая особенность — иногда нужно отключить CLI opcache (у нас он включен на скриптовых машинах).

Когда-то мы не выключили его и потеряли из-за этого 30% процессора.

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

У нас есть патчи PHP, но они мало связаны с производительностью.

Есть проблема с конкурентной блокировкой APCu — когда на один и тот же ключ нужно много писать.

Внутренняя архитектура APCu построена таким образом, что происходит глобальная блокировка ключа, и при интенсивной записи начинаются тормоза.

Поэтому у нас есть специальное расширение, которое решает эту проблему.

Это лишь частично проблема с производительностью, поскольку она влияет на время отклика, но не на потребление процессора.

Семен Катаев, Авито

Монолитное приложение, написанное на PHP, пишется уже более 11 лет. Он находится в стадии быстрого роста.

Когда компания только начинала свою деятельность, на 65 физических серверах было 65 LXC. В каждом контейнере приложений работает PHP-FPM, nginx и вспомогательное программное обеспечение для метрики и журналирования.

Ничего особенного.

За эти годы мы ни разу не добавили в монолит железо.

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

Потребление процессора и памяти последние годы падает: 65 контейнеров для монолита нам теперь достаточно.

Как вы измеряете продуктивность? Какой инструмент вы используете для измерения времени ответа клиента?

Михаил Буйлов, Мамба

Он логирует два показателя — время от запуска FPM до функции выключения и до окончания выполнения скрипта.

Вторая метрика нужна, чтобы увидеть, что происходит после функции выключения.

Измеряем JS. На самом деле это так себе показатель; сетевые каналы очень часто выходят из строя.

В результате погрузка где-то в российской глубинке начинает тормозить.

Поэтому мы смотрим на это так: «Ой, подскочило, значит, где-то что-то отвалилось».

Плюс сторонняя реклама сильно искажает метрики.

И, самое главное, приходят спамеры, а это вообще какая-то случайность.

Семен Катаев, Авито

Она мне все еще нравится.

Большая часть метрик собиралась с его помощью, но потом перешли на протокол StatsD. Теперь проводим измерения с разных точек: спереди, с серверов перед приложением, с nginx и с самого PHP-приложения.

У нас есть специальная команда производительности.

Она начала с переднего исполнения, но потом перешла на заднее.

Спереди он собирает не только JS, CSS и другую статику, но и время ответа сервера.

Прежде всего, мы ориентируемся на время отклика приложения.

Павел Мурзаков, Badoo

Используя классический Pinba для PHP, мы измеряем время выполнения PHP-скрипта с точки зрения PHP. Но у нас также есть, например, Pinba для nginx, который измеряет время отклика с точки зрения nginx. Также мы собираем метрики по клиенту.

Что мы смотрим? С одной стороны, по времени отклика.

Это не связано с планированием ресурсов.

Если плохо, то это нужно улучшать, потому что это, по сути, качество услуги.

Другое дело, что нужно как-то спланировать железо.

Наши ITOps и группы мониторинга контролируют все оборудование.

Некоторые полоски были установлены в сети, на диске.

Есть какие-то значения, после которых происходит оповещение — и мы что-то делаем.

Как показала практика, мы обычно оптимизируем под ЦП: ориентируемся на него.

Семен Катаев, Авито

В каждом LXC есть сервер StatsD, который собирает эти метрики и отправляет их дальше через коллекторы в кластер Graphite (включая ClickHouse), где и хранятся данные.

Это самодиагностика.

Также в каждом контейнере есть nginx, то есть nginx + PHP-FPM. С помощью nginx мы собираем внешние метрики, связанные со временем работы PHP-приложения.

Перед ними на отдельных серверах стоит nginx (мы называем их avi-http), который осуществляет базовую маршрутизацию, где также собираются метрики более высокого уровня, такие как время ответа, количество 500 кодов ответа и другие.

Какие инструменты у вас есть для выступления? Что вы используете чаще всего?

Михаил Буйлов, Мамба

И мы не могли придумать ничего лучше, чем написать свою собственную вещь, которую назвали Better Than Pinba. Это просто сервер счетчиков, который получает счетчики от PHP-клиента.

Мы разбросали по коду множество таймеров: каждый раз, когда мы хотим что-то измерить, мы задаем в коде начало и остановку таймера.

Модуль сам посчитает время выполнения счетчика, агрегирует накопленные счетчики в пакет и отправит их демону.

Интерфейс сам извлечет все необходимое и построит связные графики для нужного счетчика.

Одной из проблем Пинбы было отсутствие собственного интерфейса — нужно было передавать данные в RRD (тогда еще было так темно).

Итак, мы написали собственный интерфейс.

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

Мы можем увидеть где какой счетчик увеличился, или время отклика счетчика увеличилось, или количество счетчиков увеличилось.

Вы можете увидеть, когда производительность падает. Мы начинаем копать в этом направлении.

До PHP 7 мы использовали XHProf, потом он у нас перестал работать.

Вот почему мы перешли на Xdebug. Тыкаем Xdebug только тогда, когда видна проблема.

Павел Мурзаков, Badoo

Если взять XHProf с мастера, то он действительно не соберется.

Но если вы переключитесь на ветку на GitHub под названием Experimental (или что-то в этом роде), то там все отлично работает для PHP 7, готового к производству.

Проверено.

Михаил Буйлов, Мамба

У меня это не сработало.

Павел Мурзаков, Badoo

В какой-то степени вы стали пророками.

В какой-то момент нам тоже стало не хватать производительности.

Мы выполнили Пинба2 , что очень быстро.

Вы можете использовать его как замену Pinba.

Семен Катаев, Авито

Мы как раз взяли в свою работу направление производительности: собираем метрики, например, время отклика.

Мы используем StatsD. Мы пока не используем профилировщики на регулярной основе, но я знаю, что некоторые команды используют их в своих микросервисах, написанных на PHP. По-моему, New Relic даже кто-то использует. Но в контексте основного монолитного приложения мы только приближаемся к цели.

Павел Мурзаков, Badoo

Мы используем XHProf и запускаем его для некоторых запросов.

У нас всегда есть последние версии профилей XHProf. У нас есть liveprof: это наш инструмент, о нем вы тоже можете почитать в моей статье .

Все это происходит автоматически, вам просто нужно наблюдать.

Мы используем PHPSpy. У нас он не работает постоянно: когда кто-то хочет что-то посмотреть, он подходит к машине и сбрасывает профиль.

В принципе, как и в случае с Перф.

Семен Катаев, Авито

Он перестал готовиться.

Собираем кучу метрик от обращений к роутерам, контроллерам и различным моделям.

Около 60–70% внутренней сети дата-центра занимают UDP-пакеты с метриками.

На данный момент нам этого достаточно.

Теперь будем искать новые места для оптимизации.

Раз уж мы перешли к аппаратному обеспечению, занимается ли кто-нибудь в вашей компании систематическим планированием мощности? Как устроен этот процесс?

Семен Катаев, Авито

Основное планирование мощности у нас уходит на Kubernetes, где около 400 более-менее живых микросервисов написаны на PHP/Go. Мы потихоньку отрезаем куски от монолита, но он все равно растет. Мы не можем остановить его.

В целом PHP — классный язык.

На нем быстро реализуется бизнес-логика.

Павел Мурзаков, Badoo

Если мы начнем приближаться к порогу, это заметят наши коллеги.

Вероятно, они несут основную ответственность за глобальное планирование мощностей.

PHP-часть имеет основной ресурс ЦП, поэтому мы следим за ней сами.

Мы ставим перед собой следующую норму: мы не должны «съедать» более 60% кластера.

60%, а не 95%, потому что у нас есть гиперпоточность, которая дополнительно выжимает из процессора больше, чем можно выжать без него.

За это мы платим тем, что после 50% потребление процессора может вырасти непредсказуемым образом, потому что ядра гиперпоточности не совсем честны.

Михаил Буйлов, Мамба

На глаз! У нас есть определенный резерв производительности, который позволяет нам это сделать.

Мы стараемся его придерживаться.

Кроме того, мы делаем оптимизацию постфактум.

Когда видим, что что-то отвалилось, откатываемся, если все совсем плохо.

Но этого практически никогда не происходит. Или мы просто видим, что «это не оптимально, сейчас мы быстро все исправим и все будет работать как надо».

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

Вы говорите о микросервисах.

Как они взаимодействуют? Это REST или вы используете двоичные протоколы?

Семен Катаев, Авито

Есть более быстрые реализации: тот же protobuf, gRPC. Это в наших планах, но точно не приоритет. Имея более 400 микросервисов, сложно перенести их все на новый протокол.

Есть много других мест для оптимизации.

Сейчас у нас определенно нет на это времени.

Павел Мурзаков, Badoo

Есть сервисы, а еще есть Kafka, свой протокол поверх Google protobuf. Мы бы, наверное, использовали gRPC, потому что это круто, у него есть поддержка всех языков, возможность очень легко связывать разные части.

Но когда нам это понадобилось, gRPC еще не существовало.

Но был протобуф, и мы его взяли.

Поверх него добавлялись разные вещи, чтобы это была не просто сериализация, а полноценный протокол.

Михаил Буйлов, Мамба

Есть сервисы, в основном написанные на C. Мы используем JSON-RPC, потому что это удобно.

Вы просто открыли сокет во время отладки кода на языке C и быстро написали то, что хотели.

Что-то вернулось к тебе.

С protobuf сложнее, потому что нужно использовать некоторые дополнительные инструменты.

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

У вас огромные базы данных.

Если вам нужно изменить схему в одном из них, как вы это сделаете? Какая-то миграция? Если эти миграции займут несколько дней, как это повлияет на производительность?

Михаил Буйлов, Мамба

Есть осколок.

Шард меняется довольно быстро, потому что одновременно происходит множество параллельных изменений.

На смену большого стола с профилями уходит около трёх часов.

Мы используем инструменты Perkonov, которые не блокируют его для чтения и записи.

Кроме того, мы развертываем перед изменением, чтобы код поддерживал оба состояния.

После альтера также развертываем: развертывание происходит быстрее, чем при использовании некоторых схем.

Павел Мурзаков, Badoo

Если взять таблицу «Пользователь», то в ней очень много шардов.

Не скажу навскидку, сколько именно столов будет на одном сервере: идея в том, что маленьких много.

Когда мы меняем схему, мы, по сути, просто вносим изменения.

На каждом маленьком столе это происходит быстро.

Есть другие репозитории — там другие подходы.

Если есть одна огромная база данных, есть инструменты Перконова.

В общем, мы используем разные вещи в соответствии с нашими потребностями.

Наиболее распространенное изменение — это изменение в этой огромной сегментированной базе данных спотов, в которых у нас уже есть встроенный процесс.

Все это работает очень просто.

Семен Катаев, Авито

Почти каждые два часа.

Что касается работы с базой данных, то это отдельный вопрос.

Миграции есть, они выкатываются автоматически.

Это обзор администратора базы данных.

Существует возможность пропустить миграцию и выполнить ее вручную.

Миграция будет автоматически перенесена в промежуточную версию при тестировании кода.

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

Код должен быть таким, чтобы работать со старыми и новыми структурами базы данных.

Мы часто делаем несколько шагов для развертывания функции.

За два-три выкатывания можно получить желаемое состояние.

Аналогично, существуют огромные базы данных, сегментированные базы данных.

Если посчитать все микросервисы, то в день точно 100–150 развертываний.

Я хотел бы знать, какое у вас стандартное время ответа серверной части? Когда вы понимаете, что нужно оптимизировать дальше или пора заканчивать? Существует ли «среднее значение по больнице»?

Павел Мурзаков, Badoo

Давайте рассмотрим все по отдельности.

Мы пытаемся понять, насколько это критично.

Некоторые конечные точки обычно запрашиваются в фоновом режиме.

На пользователе это никак не сказывается, даже если время отклика составляет 20 секунд. Это будет происходить в фоновом режиме, разницы нет. Главное, чтобы некоторые важные дела делались быстро.

Возможно, 200 мс — это еще нормально, но небольшое увеличение уже имеет значение.

Михаил Буйлов, Мамба

Мы стремились к 200 мс.

Потом появился PHP 7 — и мы начали фокусироваться на 100 мс.

Это «средний показатель по больнице».

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

Поэтому мы скорее сосредоточимся на развертывании и увеличении времени отклика после него.

Семен Катаев, Авито

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

Мы посчитали, сколько еще покупателей, транзакций, звонков, переходов и так далее.

Из этих данных можно понять, что в какой-то момент ускорение перестает иметь смысл.

Например, если время отклика одной из страниц с 90 мс ускорить до 70 мс, это дало +2% покупателей.

А если разогнаться с 70 мс до 60 мс, то уже плюс 0,1% покупателей, который вообще входит в погрешность.

Так же, как и с ребятами, все сильно зависит от страницы, с которой мы работаем.

В целом по Авито 75-й перцентиль составляет около 75 мс.

На мой взгляд это медленно.

Сейчас мы ищем места для оптимизации.

До того, как мы перешли на микросервисы, все происходило гораздо быстрее, и мы пытаемся оптимизировать производительность.

И вечный вопрос: железо или оптимизация? Как понять, стоит ли покупать железо или лучше вложиться в оптимизацию? Где граница?

Семен Катаев, Авито

Мне кажется, в крупных компаниях, таких как Badoo, моя и Яндекс, много разработчиков разного уровня.

Есть как младшие разработчики/стажеры, так и ведущие разработчики.

Мне кажется, что всегда есть больше возможностей для оптимизации/доработки.

Железо – это последний шаг.

Для монолита 65 LXC мы очень давно не добавляли железо.

Загрузка процессора - 20%.

Мы уже думаем о переносе их в кластер Kubernetes.

Павел Мурзаков, Badoo

Но у меня совершенно противоположная точка зрения.

В первую очередь я бы посмотрел на железо.

Можно ли добавить оборудование и будет ли это дешевле? Если да, то проще решить проблему аппаратно.

В это время разработчик может сделать что-то еще полезное.

Время разработчиков стоит денег.

Железо тоже стоит денег, поэтому надо сравнивать.

Что из этого важнее, пока неясно.

Если оба стоят одинаково, то выигрывает оборудование, потому что разработчик сможет что-то сделать в это время.

В частности, с точки зрения серверной части PHP мы не можем этого сделать.

Оптимизация обходится нам гораздо дешевле, чем покупка оборудования.

О остановке.

С планировочной точки зрения у нас есть что-то вроде бара.

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

С другой стороны, есть еще и качество обслуживания.

Если мы видим, что время отклика нас где-то не устраивает, то нам нужно его оптимизировать.

Михаил Буйлов, Мамба

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

Если пользователей мало, то проще купить дополнительное оборудование и поручить работу по развитию проекта разработчику.

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

Семен Катаев, Авито

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

Если у вас один сервер, то вы легко можете купить еще два-три сервера и забыть об оптимизации.

Если команда маленькая, то пусть покупают сервера.

Если команда большая и у вас два-три дата-центра, то покупка шести дата-центров — это не так дешево и не так быстро.

Раз уж у нас PHP-митап, то должна быть услышана такая фраза: зачем нам PHP, если у нас постоянно такие проблемы? Давайте перепишем его на Go, C, C#, Rust, Node.js! Считаете ли вы, что подход к переписыванию в целом оправдан? Есть ли какие-то задачи, ради которых стоит это сделать и потратить на это время?

Семен Катаев, Авито

Это действительно позволяет решать бизнес-задачи.

Он достаточно быстр.

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

Портировав их в сыром виде на Golang, Java, Python, вы получите ту же производительность.

Вся проблема в том, что там очень много легаси.

Внедрение нового языка, на мой взгляд, имеет смысл с целью расширения стека и возможностей найма.

В настоящее время довольно сложно найти хороших PHP-разработчиков.

Если мы внедрим Голанг в техрадар, то сможем нанимать сусликов.

На рынке мало PHP-шников и немного сусликов, но вместе их уже много.

Например, у нас был один эксперимент. Мы наняли разработчиков C#, готовых изучать новые языки — мы просто расширили набор сотрудников.

Если вы говорите людям, что мы научим их писать на PHP, они говорят, что лучше не надо.

А если мы предложим им научиться писать на PHP, Go, а также пообещаем им возможность писать на Python, то люди охотнее откликнутся.

Для меня речь идет о расширении возможностей найма.

В других языках есть некоторые вещи, которых действительно не хватает PHP. Но в целом PHP вполне достаточно для решения бизнес-задач и реализации крупных проектов.

Павел Мурзаков, Badoo

Просто переписывать нет смысла.

PHP — довольно продуктивный язык.

Если сравнивать его с другими скриптовыми некомпилируемыми языками, то он, наверное, будет чуть ли не самым быстрым.

Переписать на какие-нибудь языки типа Go и другие? Это разные языки, у них разные проблемы.

Писать на них все же сложнее: это не так быстро и много нюансов.

Но тем не менее есть вещи, которые на PHP писать либо сложно, либо неудобно.

Лучше писать какие-то многопроцессные и многопоточные вещи на другом языке.

Пример задачи, где неиспользование PHP оправдано в принципе, любые СХД.

Если это сервис, который хранит много памяти в памяти, то PHP, вероятно, не лучший язык, поскольку у него очень большие накладные расходы на память из-за динамической типизации.

Получается, что вы сохраняете 4-байтовый int, но теряется 50 байт. Я, конечно, утрирую, но накладные расходы все равно очень большие.

Если у вас есть какое-то хранилище, то лучше написать его на другом компилируемом языке со статической типизацией.

Точно так же, как некоторые вещи, требующие многопоточного выполнения.

Михаил Буйлов, Мамба

Перевод на Go — решение проблемы путем перевода кода с динамической типизации на статическую типизацию.

За счет этого все происходит быстрее.

Конкретно для Go мой план содержит задачи для конкретного потока данных.

Например, если есть какой-то поток данных, который нужно преобразовать в более удобные форматы, это идеальный вариант. Демон поднялся, он принимает на вход один поток данных, а выводит другой.

Памяти съедает мало.

PHP в этом случае съедает много памяти: нужно тщательно следить за ее очисткой.

Трансляция на Go — это трансляция на микросервисы, потому что весь код не вырежешь.

Нельзя взять и переписать целиком.

Перевод на микросервисы — более глубокая задача, чем перевод с одного языка на другой.

Нужно сначала решить ее, а потом думать, на каком языке писать.

Самое сложное — выучить микросервисы.

Семен Катаев, Авито

Многие сервисы написаны на PHP и имеют разумное время отклика.

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

На самом деле они иногда делают что-то быстрее, чем суслики.

У нас есть тенденция нанимать сусликов, переходя на Го.

Но большая часть нашего кода по-прежнему написана на PHP, и так будет еще как минимум несколько лет. Здесь нет настоящей гонки; мы не решили, что Го лучше или хуже.

В день на монолит выкатывается шесть релизов.

В нашем чате «Авито деплой» есть список задач, которые развернуты.

В каждом релизе в день выкатывается не менее 20 задач: пять-шесть релизов в день, примерно 80 задач, которые люди выполнили по этим задачам.

Все это делается на PHP.

Вы оптимизируете за счет сокращения функциональности? А как уследить за накопившимися старыми устаревшими функциями, которые никому не нужны?

Семен Катаев, Авито

Есть психологический момент: вы запустили новую функцию — молодец.

Запустил огромную новую функцию — вы молодцы! Когда менеджер или разработчик заявляет, что они удалили какую-то функцию (вывели из эксплуатации), они не получают этой оценки.

Его работы не видно.

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

И результат от этого может быть поистине колоссальным.

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

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

Это сложный процесс.

Михаил Буйлов, Мамба

И не всегда есть возможность быстро его вырезать.

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

Это влечет за собой дикое количество зависимостей, которые тоже необходимо исправлять.

Это не всегда возможно, и руководство должно быть об этом осведомлено.

Менеджер ставит задачу, вы ее оцениваете.

Ты говоришь: «Знаешь, парень, я буду этим заниматься полгода.

Готовы ли вы подождать шесть месяцевЭ» Он говорит: «Нет, давайте подумаем, что нужно вырезать, что можно оставить.

Что принципиально необходимо, а над чем нужно поиграться».

Вот как все это происходит.

Павел Мурзаков, Badoo

Если он видит, что либо то, либо другое, то уточняет у продакт-менеджера, действительно ли это необходимо, можно ли где-то что-то убрать.

Иногда бывает, что изменения не критичны, и менеджеры быстро идут на уступки, когда узнают, что эта штука Теги: #php #производительность #оптимизация #оптимизация кода #бэкенд #Высокая производительность #php #Конференции

• Ремонт Apple Macbook В Дели

  19 Oct, 24

• Ноутбук Sony Vaio Vpc-Ea 2S1E/B

  19 Oct, 24

• 7 Дизайнерских Услуг И Инструментов Для Недизайнеров

  19 Oct, 24

• Российский Рынок Венчурных Инвестиций В Ит- И Интернет-Компании Рухнул На 43% В 2015 Году

  19 Oct, 24

• Ищите, Голосуйте И Некоторые Другие Обновления Gt

  19 Oct, 24

• В Двадцатый Раз Об Интервью

  19 Oct, 24

• Как Отобразить Результат Большой Выборки В Виде Страниц

  19 Oct, 24

• Антипаттерны Дизайна: Полтергейсты

  19 Oct, 24

• Hp Не Хочет Производить Камеры

  19 Oct, 24

• Доход Создателей Firefox В 2005 Году Составил $52,9 Миллиона.

  19 Oct, 24