Архитектура Symfony2

Первое, что выделяет данный PHP-фреймворк среди толпы остальных — это гибкая архитектура Symfony2, которая позволяет быстро разрабатывать приложения. В этой статье мы коротко расскажем о ее основных особенностях.

Symfony Components

Работа Symfony2 основана на использовании разделенных (decoupled) компонентов многократного использования — Symfony Components. Все они решают распространенные проблемы, с которыми приходиться сталкиваться в процессе веб-разработки. Кстати, некоторые другие PHP-фреймворки используют компоненты Symfony2, например:

1. Silex (компоненеты BrowerKit, CssSelector, DomCrawler, EventDispatcher, HttpFoundation, HttpKernel, Routing, Form, Translation и Validator).
2. Behat (компоненеты Console, DependencyInjection, EventDispatcher, Finder, Yaml, Config и Translation).
3. FLOW3 (компоненет YAML).

В основе популярной CMS Drupal8 также лежит использование компонентов Symfony2, таких как HttpKernel, HttpFoundation, EventDispatcher, YAML, Routing, Twig и многих других.

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

Структура директорий

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

app/ — здесь вы найдете все данные по конфигурации приложения.

src/ — исходный код.

web/ — корневая web-директория.

Особенности web-директории

В корневой web-директории содержатся все публичные и статичные файлы, используемые и загружаемые таблицы стилей, файлы JavaScript, а также фронт-контроллер.

web/app.php

Архитектура фреймворка Symfony2 основана на фронт-контроллере web/app.php. Главной входной точкой в конфигурации приложения является класс AppKernel. Входящие параметры конструктора: prod — инициализация окружения, в котором будет работать приложение; второй параметр определяет, будет ли использоваться отладочная информация при работе. Метод handle принимает объект класса Request, сформированный из глобальных переменных, и возвращает клиенту объект класса Response. Класс AppKernel должен реализовать два метода:

registerBundles — возвращает массив бандлов, необходимых для работы.

app/AppKernel.php

registerContainerConfiguration — загружает конфигурацию приложения из директории app/config, соответствующую окружению, переданному в конструктор.

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

Сервис-ориентированная архитектура Symfony2 предполагает разделение функций на модули, которые выделяются в независимые сервисы. Она является основой Symfony2.

Почему же бандл, а не плагин?

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

Бандлы заслужено носят звание «высшей касты» в Symfony2. И это звание только лишний раз подчеркивается той гибкостью, которая имеется при использовании уже существующих бандлов или при создании новых. Исключительная гибкость — это то, что позволяет вам самостоятельно настроить особенности приложения и выполнить оптимизацию так, как будет удобно именно вам. Составными частями ядра фреймворка также являются FrameworkBundle, DoctrineBundle, SwiftmailerBundle, AsseticBundle.

Написав на XML, YAML или PHP конфигурационные файлы, вы сможете по отдельности настроить каждый бандл. Для наглядности посмотрите на конфигурацию по умолчанию:

app/config/config.yml

Каждая запись, имеющаяся в config.yml, отвечает за точную настройку бандла. Стандартную конфигурацию задает каждое окружение, определяя настройку при помощи специфического конфигурационного файла.

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

Вот некоторые из самых популярных бандлов по результатам опроса разработчиков:

1. FOSUserBundle (60%)
2. FOSRestBundle (30%)
3. KnpMenuBundle (25%)
4. StofDoctrineExtensionsBundle (25%)
5. JMSSerializerBundle (24%)
6. SonataAdminBundle (24%)

Принцип работы кэша и логов

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

Частично на этот вопрос поможет ответить система кэширования. Анализ приложения происходит только при первом запросе, далее информация компилируется в оптимизированый PHP код и сохраняется в соответствующей папке app/cache/. Среда разработки Symfony2 достаточно интеллектуальна, чтобы своевременно очищать кэш при внесении изменений в файл. Для устранения возникающих проблем или ошибок, загляните в папку app/logs/ — в ней хранятся все логи о запросах.

Как выглядит интерфейс командной строки?

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

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

Архитектура Symfony2 в диаграммах

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

Все запросы, которые поступают к приложению, вначале попадают на фронт-контроллер, который создает экземпляр AppKernel для обработки запроса:

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

Создание веб-приложений на SYMFONY 2/3/4: быстро, профессионально, под ключ

Разработка веб сайтов

Symfony — php-фреймворк для разработки сложных и производительных веб-приложений. Это мощная и функциональная платформа с продуманной архитектурой и подробной документацией. Симфони создана для долгосрочных, трудоемких, нестандартных и масштабных проектов. С ее помощью создана популярная CMS Drupal и может быть реализован любой ваш проект.

Что такое фреймворк

Фреймворк — каркас веб-приложения. Платформа для разработки делает написание кода проще и структурирование. У фреймворков есть правила оформления и модули — библиотеки и другие инструменты, облегчающие сборку готового проекта. От платформы, но не только, зависит скорость разработки, простота совместной работы нескольких специалистов, а также масштабирование и модернизация веб-приложения. Кроме того, фреймворк влияет на то, насколько быстро и стабильно будет работать приложение или сайт.

Использовать фреймворк для разработки приложений всегда выгодно для проектов со сложной бизнес-логикой или масштабных веб-приложений, где важна производительность, скорость работы, надежность и безопасность. На чистом коде пишутся только очень простые программы или очень нагруженные, получающие от 10 тысяч обращений в секунду, где нужна низкоуровневая оптимизация. CMS, готовую систему управления контентом, выгодно устанавливать, если у вас, например, маленький интернет-магазин или блог. Это будет дешевле и быстрее. Во всех остальных случаях — первоочередная задача выбрать фреймворк. У каждого языка программирования есть несколько фреймворков, а Symfony один из созданных для PHP.

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

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

Опытные разработчики

В Симфони один из самых высоких порогов вхождения. Чтобы изучить все нюансы платформы и использовать их максимально, нужно много времени, не менее трех лет и еще больше практического опыта. За разработку проектов на Symfony берутся только те, кто уверен в своих силах. Если вы нет, просто предложите создать приложение на Laravel, как самом распространенном PHP-фреймворке, или одной из платформ JavaScript. Кстати, это не всегда плохо – платформу нужно выбирать исходя из задач вашего бизнеса.

Инновации

Основная особенность Symfony – активное использование нестандартных решений для усовершенствования. В этом фреймворке для php много адаптированных идей из других языков, как, например зависимость и модульность с Java и их количество постоянно увеличивается. На практике это означает, что если у вас действительно инновационная идея для web-приложения, лучше всего реализовывать ее с использованием Симфони.

Быстрая разработка и легкая поддержка

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

Гибкость и расширяемость

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

Документация

Симфони — свободное и бесплатное ПО, над улучшением которого работает компания-создатель SensioLabs и большое коммьюнити разработчиков. Программисты, столкнувшиеся с проблемой, всегда смогут обратиться за помощью к официальным представителям или сообществу. Сейчас над улучшением Симфона работает более 3000 человек со всего мира, а в активной части коммьюнити в 200 раз больше разработчиков.

Условные ограничения

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

Комфорт

В Симфоне есть готовые решения для многих второстепенных функций, а также панель инструментов web-настройки, страницы ошибок, поддержка сред разработки и многое другое, что упрощает, а значит делает удобнее и ускоряет работу над проектом. Одна из главных ценностей Symfony – творческая свобода. Фреймворк стремится сделать за разработчика всю рутинную часть программирования, чтобы он мог сосредоточиться на действительно важных задачах, от которых зависит успех и прибыльность web-приложения.

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

Бизнес знает свои потребности, а мы — как их реализовать.

Создаем и разрабатываем устойчивые корпоративные сайты и резвые промо-лендинги. Разрабатываем web сервисы. Наши продукты выдерживают огромную нагрузку и надёжно служат клиентам.

Мы перенесли старое приложение Symfony 2 с PHP 5.6 на PHP 7.1 | Пьер Роллан | TheFork Engineering Blog

Приложение Symfony 2.1, если быть более точным. Чего ждать? В 2020 году? Да. Контекст.

Что это за приложение, как оно было создано?

Приложение, о котором мы говорим, на самом деле представляет собой API, который годами использовался для обслуживания всех интерфейсов TheFork B2C, таких как настольный веб-сайт, мобильный веб-сайт, а также приложения для iPhone и Android (для простоты). Он был создан примерно в 2012 году с использованием технологий той эпохи (PHP 5.4, новый Symfony 2 и т. д.). Ярче, чем когда-либо в 2012 году. Отличительной особенностью, которую представила Symfony 2, по сравнению с Symfony 1, была идея разделения кода на пакеты и создания приложений на основе этой концепции. Но должны ли мы были разделить код на пакеты внутри нашего приложения (по функциональным областям) или мы должны были просто разделить многократно используемые функции и поместить функциональную часть приложения в один пакет? Что ж, если последнее и является тем, что на самом деле рекомендуется сейчас, то оно не всегда было кристально ясным, даже в официальной документации Symfony, в которой указывалось, что все фрагменты кода должны принадлежать к пакетам. Итак, в TheFork мы сделали то, что было самым очевидным в то время. Мы разделяем части, которые могут использоваться другими приложениями (B2B API, бэк-офис и т. д.), на общие пакеты, а также разделяем код внутри нашего приложения на функциональные пакеты (ресторан, пользовательский, бронирование, лояльность и т. д.).

Все это привело после многих лет разработки к созданию большого монолита, содержащего всю логику B2C TheFork и основанного на Symfony 2. 1-совместимых зависимостях, либо внешних по отношению к TheFork, либо внутренних и общих для всех PHP-проектов TheFork.

Еще одна заметка о нашей инфраструктуре. Этот API размещается у хостинг-провайдера и работает вместе с другими приложениями PHP. Поскольку TheFork в настоящее время переходит на AWS (но еще не полностью), затраты на масштабирование, если оно нам понадобится, будут большими.

Время летит, технологии меняются

Вы знаете, как это бывает. С самого начала было создано много кода, основанного на интерфейсах, предоставляемых всеми пакетами, от которых зависит наш API. Эти связки также развивались со временем. Некоторые из них стали совместимы с PHP 5.5, 5.6, а затем с 7.0 до 7.4. Некоторые из них исчезли, сменившись другими, некоторые перестали поддерживаться, и многие интерфейсы изменились. Что касается внутренних пакетов, то по мере того, как количество проектов, использующих их, росло, поддерживать их для всех версий PHP и всех версий Symfony становилось все труднее и труднее. Некоторые патчи были созданы, иногда, для срочных нужд, но множество факторов (нехватка времени, отсутствие настоящего владельца и т. д.) свели на нет все шансы на реальную ремонтопригодность. Этот API месяц за месяцем становился устаревшим, со все большим и большим техническим долгом. Сначала контролировал. Он был быстро переведен на PHP 5.5, а несколько лет спустя на PHP 5.6. Но все же Symfony 2.1. Чем больше он становился, тем выше стоимость обновления версии фреймворка, которая ниже версии 2.4 приводила к нарушениям обратной совместимости.

Микросервисы

В начале 2017 года произошли большие изменения. Было принято решение разбить этот монолит на микросервисы. Вся бизнес-логика и данные, хранившиеся в нашем API, должны были быть перенесены в более мелкие приложения, разделенные по функциональным областям, и API должен был тихо умереть, как только все было перенесено.
Еще в 2020 году, если некоторым из этих микросервисов удалось стать настоящими владельцами своей области, другие домены по-прежнему полностью унаследованы и по-прежнему обрабатываются нашим API. В результате это по-прежнему обязательный путь, несмотря на все усилия, направленные на то, чтобы заставить его умереть. По нему идет трафик, иногда критический для бизнеса.

Бизнес растет

Наконец, TheFork уже не та компания, что была восемь лет назад. Сегодня она присутствует в 22 странах, приобрела несколько других компаний по всему миру и признана настоящим лидером в Европе и Южной Америке в своей области. Это означает больше пользователей и больше трафика, но также и рекламы, за которой следуют пики в инфраструктуре… и ежедневное массовое сканирование Google. И вот именно этот последний пункт и выбил муравейник.

Узнаете ли вы, когда появится Google?

Помогите! Что мы можем сделать?

Как вы можете видеть на этой картинке, Google сильно навредил нашему бедному приложению. Как мы знаем, масштабировать по горизонтали было невозможно. Так что мы могли сделать? Вот три варианта, которые мы рассмотрели:

• Ускорить переход на микросервисы? Мех. Прошло уже три года, и даже если бы там была спецгруппа, ситуация была слишком срочной и слишком критической.
• Ускорить переход от нашего хостинг-провайдера к AWS? О, нет. Это было слишком рискованно, и оставалось слишком много неизвестных. Проект был действительно большим, и он полагался на множество баз данных, с настраиваемыми стратегиями сегментов и так далее.
• Перейти с PHP 5 на PHP 7? Что ж, многие компании сделали этот шаг до нас и быстро добились впечатляющих улучшений. Кроме того, известно, что PHP-сообщество крайне осторожно относится к BC-breaks, так что это казалось выполнимым шагом за короткий промежуток времени.

С чего начать?

Несколько стратегий пришли нам на ум, когда мы начали думать об этом. Переходим на PHP 7, запускаем тесты, исправляя каждую ошибку одну за другой? Остаемся на PHP 5 и обновляем зависимости одну за другой? Хорошо. Некоторые подсказки были в нашем распоряжении, чтобы начать.

— Поддержка PHP 7 в Symfony начинается с Symfony 2. 3, поэтому нам пришлось перенести Symfony как минимум на 2.3.
— Мы должны были поддерживать обе версии PHP (5.6 и 7.1), чтобы мы могли откатить версию PHP, если что-то пойдет не так с PHP во время производства.

Docker как рабочая среда

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

Основными различиями между двумя средами были имена пакетов расширений PHP, которые обычно имеют префикс « php5-» или « php7.1-». К счастью, PHP-образы Docker поставляются с удобными командами, такими как « docker-php-ext-install » или « docker-php-ext-enable », что позволяет легко переключать наш Dockerfile, просто изменяя директиву « FROM ». вверху файла.

Composer нам в помощь

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

Опять же, мы должны были быть совместимы с обеими версиями PHP, поэтому мы решили работать с самой последней, PHP 7.1, так как она будет целевой для нашей производственной среды. И мы добавили эти строки в Composer для обеспечения обратной совместимости.

 
 «требуется»: { 
 «php»: «> = 5.6.29», 
 … 
 }, 
 …, 
 «конфигурация»: { 
 «платформа»: { 
 «php»: «5.6.29 ” 
 } 
 } 

Таким образом, мы были уверены, что Composer установит 5.6-совместимые зависимости в нашей среде 7.1.

Затем мы устанавливаем для всех версий «*» в composer.json , в разделе « require » и « require-dev ». Да. «*». Мы сохранили идентификаторы версий, которые были ранее установлены (через файл composer.lock ), чтобы обязательно откатить зависимость до ее предыдущей версии, если поведение слишком сильно изменилось, что приведет к сбою нашего приложения. И мы удалили каталог /vendor , файл composer.lock и запустили « composer install ». Сделай дело, Композитор. Найдите для меня самые последние версии для моей конфигурации, совместимые с 5.6 и 7.1.

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

К счастью для нас, все неподходящие зависимости были внутренними, поэтому одну за другой мы сделали их совместимыми с Symfony 2.8 и PHP 7.1. Это заняло некоторое время, так как у нас было около 20 внутренних зависимостей, и почти все они нуждались в исправлении, чтобы работать с более новыми версиями Symfony и PHP.

Но мы это сделали. После исправления каждой проблемной внутренней зависимости композитору удалось установить все, и он был совместим с обеими версиями PHP. Значит, все кончено? ХА-ХА. Ты хочешь.

Тесты

В TheFork этот API использует 4 набора тестов. Модульные тесты, функциональные тесты PHPUnit, функциональные тесты Behat и, наконец, сквозные тесты. Модульные тесты будут тестировать небольшие фрагменты кода, такие как функции, функциональные тесты будут тестировать различные методы, которые можно вызывать в API, имитируя любую зависимость от другого проекта, а сквозные тесты затрагивают интерфейсы на среду preprod и перейти к самым нижним слоям. Тесты обязательны перед выполнением такой миграции. Без них мы не смогли бы его исполнить.

Модульные тесты

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

Начав с исправления модульных тестов, вы получите хорошее представление о выигрыше, который вы получите, переключив версию PHP, особенно в отношении времени выполнения. Мы смогли быстро сказать всем сторонам: «Эй, я не знаю, когда это закончится, но определенно это того стоит».

Функциональные тесты

Исправление функциональных тестов — одно из самых приятных достижений. Когда это будет сделано, мы поймем, что все ближе и ближе приближаемся к победе, поскольку наш API отвечает вызывающей стороне так, как мы хотим, и опирается на другие API, которые теоретически не должны были измениться. Кроме того, это может быть болезненно. Возможно, мы исправили множество модульных тестов, поскольку все смоделировано, чтобы сосредоточиться именно на том, что делают функции, именно во время сеанса функционального тестирования вы обнаружите все несоответствия между вашим приложением и всеми зависимостями, которые вы обновили с помощью Composer, или исправлено, чтобы сделать их совместимыми с новыми версиями Symfony.

Сквозные тесты

Запуск тестов перед выпуском в препродукт

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

Настройка среды preprod

Если вы помните, что я сказал ранее, наше приложение жило вместе с другими PHP-приложениями, поэтому мы не переходили на PHP 7. 5 и PHP 7 приложений. Я с самого начала кое-что скрывал от тебя. Наше приложение — это не только API. Он также содержит множество рабочих процессов, в основном потребителей RabbitMQ, развернутых на других серверах. Итак, чтобы не усложнять, мы
— установил специфичные для php7 библиотеки и двоичные файлы и переименовал исполняемый файл PHP 7 php в php7
— заставил nginx указывать на сокет php7.1 fpm
— заставил рабочих использовать php7 CLI вместо php

Запуск тестов навсегда

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

Развертывание

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

Мы начали с выпуска нашей кодовой базы на PHP 5.6, чтобы иметь только одну вещь для отката, если что-то пойдет не так. И, конечно же, нам удалось найти некоторые проблемы, которые мы быстро устранили. Убедившись, что уровень предупреждений/ошибок вернулся к «нормальному», мы решили переключить версию PHP. Вот так, детки, мы и перешли на PHP 7.

Хорошо, но… оно того стоило? ДА.

Ответ API во время сканирования Google до (голубой) / после (темно-синий) миграции

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

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

Вы хотите работать с нами? Пожалуйста, посетите https://careers.thefork.com

Symfony 2. Проект миграции на php 7 с php5.5. Проблемы с производительностью

Задать вопрос

спросил
6 лет, 8 месяцев назад

Изменено
5 лет, 6 месяцев назад

Просмотрено
1к раз

У меня есть один проект ~4 года назад, я начал с 5. 3 и Symfony 2.0, перешел на 5.5 и S2.3. На данный момент я перешел на S2.8 и хочу перейти на php 7.

Поскольку вокруг производительности PHP 7 было так много кучи, мне не терпелось проверить производительность моего проекта в dev env.

Итак, запуск теста в dev env; service находится на бродячем хосте, имеющем как php5-fpm, так и php7.0-fpm, закрытие одного и установка другого.

Я ожидал, что php7 превзойдет php5, но в основном кажется, что php7 в 1,5-2 раза медленнее в моей локальной среде разработки.

Что я делаю не так? Или я должен как-то переписать свое приложение?

phpinfo:
PHP 7 http://pastebin.com/a6a76vE2
php 5 http://pastebin.com/4GBXNmBB

P.S. Да, я понимаю, что запуск тестов в локальной среде разработки не является на 100% достоверным и чистым, но мне нужно только понять, быстрее ли php7, чем php5, как было сказано.

U1

Самое смешное, что blackfire ясно показывает, что php 7 на ~45% быстрее, чем php 5. Но когда я осаду, я вижу, что производительность падает.

U2

Вот более или менее моя пользовательская конфигурация для dev env. То же самое для php5.5 и php7:

 [дата]
date.timezone = Европа/Таллинн
[PHP]
memory_limit = 512M
expose_php = Выкл.
cgi.fix_pathinfo = 0
post_max_size = 10M
upload_max_filesize = 10M
максимальное_время_исполнения = 60
реальный_кэш_размер = 4096к
realpath_cache_ttl = 7200
error_reporting = E_ALL | E_STRICT
log_errors = Вкл.
error_log = /var/log/php.errors.log
display_errors = Вкл.
display_startup_errors = Вкл.
html_errors = Вкл.
; xdebug
xdebug.remote_enable = Вкл.
xdebug.remote_port = 9001
xdebug.max_nesting_level = 200
xdebug.remote_log = /tmp/xdebug.log
xdebug.remote_connect_back = вкл.
xdebug.idekey = "бродяга"
[opcache]
opcache.enable_cli=0
opcache.save_comments=1
opcache.memory_consumment=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=66000
opcache.fast_shutdown=1
opcache.enable=1
opcache.revalidate_freq=5
opcache. validate_timestamps=1
 

• php
• производительность
• symfony
• php-7

11

Несколько шагов для глобальной оптимизации кода PHP и для PHP7:

• самообновление композитора
• обновление композитора
• composer dumpautoload -a
• активировать zend opcache (или любой другой установленный php opcache)
• в php.ini:
  • opcache.max_accelerated_files=20000 (или больше)
  • opcache.validate_timestamps=1
  • opcache.revalidate_freq=10 (или больше)
  • xdebug.default_enable=0
• перезапустить службу php-fpm7

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

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

Должен отметить, что в нашем случае после перехода с PHP5.

This entry was posted in Популярное