Laravel действительно такой медленный?

Я только начал использовать Laravel. Я еще почти не написал кода, но мои страницы загружаются почти за секунду!

Это немного шокирует меня, когда мои приложения без фреймворка и приложения NodeJS занимают ~ 2 мс. Что делает Laravel? Это ненормальное поведение, не так ли? Нужна ли доработка?

Laravel на самом деле не такой медленный. 500-1000 мс - это абсурд; В режиме отладки я уменьшил его до 20 мс.

Проблема заключалась в общих папках Vagrant / VirtualBox +. Я не знал, что они нанесли такой удар по производительности. Я предполагаю, что, поскольку у Laravel так много зависимостей (загружает ~ 280 файлов), и каждый из этих файлов читается медленно, складывается очень быстро.

kreeves указал мне в правильном направлении, это сообщение в блоге описывает новую функцию в Vagrant 1.5, которая позволяет вам синхронизировать ваши файлы с виртуальной машиной вместо использования общей папки.

В Windows нет собственного клиента rsync, поэтому вам придется использовать cygwin . Установите его и обязательно отметьте Net / rsync. Добавьте C:\cygwin64\binк своим дорожкам. [Или вы можете установить его на Win10 / Bash]

Vagrant представляет новую функцию . Я использую Puphet, поэтому мой Vagrantfile выглядит немного забавно. Мне пришлось настроить его, чтобы он выглядел так:

  data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != '' && folder['id'] != ''
      config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", 
        id: "#{folder['id']}", 
        type: "rsync",
        rsync__auto: "true",
        rsync__exclude: ".hg/"
    end
  end

Как только вы все настроите, попробуйте vagrant up . Если все идет гладко, ваша машина должна загрузиться и скопировать все файлы. Вам нужно будет запустить vagrant rsync-autoтерминал, чтобы файлы были в актуальном состоянии. Вы немного заплатите за задержку, но это того стоит!

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

Еще один вариант - использовать lsyncd . Я имел большой успех, используя это на хосте Ubuntu -> гость FreeBSD. Я еще не пробовал на хосте Windows.

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

Теперь я расскажу о проблеме:

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

Laravel использует множество библиотек symfony, и, как вы можете видеть в тестах techempower , symfony занимает очень низкое место (по меньшей мере, последнее). Вы даже можете обнаружить, что тест Laravel находится почти внизу.

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

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

Обычный компромисс:

 Easy = Slow, Hard = Fast

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

Хотя и не слишком. Я просто пытаюсь доказать, что easy = slow:

Ruby имеет очень хорошую репутацию в плане ремонтопригодности и простоты изучения, но он также считается самым медленным среди python и php, как показано здесь .

Да - Laravel действительно такой медленный. Ради этого я создал приложение POC. Простой роутер, с формой входа. Я мог получить только 60 RPS с 10 одновременными подключениями на сервере цифрового океана за 20 долларов (оперативная память несколько ГБ);

Настроить:

2gb RAM
Php7.0
apache2.4
mysql 5.7
memcached server (for laravel session)

Я запустил оптимизацию, автозагрузку дампа композитора и т. Д., И он фактически снизил количество запросов в секунду до 43. .

Проблема в том, что приложение отвечает через 200-400 мс. Я запустил AB-тест с локального компьютера, на котором был включен laravel (т.е. не через веб-трафик); а у меня всего 112 RPS; время отклика на 200 мс быстрее, в среднем 300 мс.

Для сравнения я протестировал свое производственное приложение PHP Native, выполняющее несколько миллионов запросов в день на AWS t2.medium (x3, с балансировкой нагрузки). Когда у меня было 25 одновременных подключений с моего локального компьютера к этому через Интернет через ELB, я получил примерно 1200 запросов в секунду. Огромная разница на машине с загрузкой и на странице входа в Laravel.

Это страницы с сеансами (elasticache / memcached), поиском в Live DB (кэшированные запросы через memcached), активами, загруженными через CDN и т. Д. И т. Д. И т. Д.

Что я могу сказать, laravel накладывает на вещи около 200-300 мсек. Это нормально для представлений, созданных PHP, в конце концов, такая задержка допустима при загрузке. Однако для представлений PHP, которые используют Ajax / JS для обработки небольших обновлений, он начинает казаться вялым.

Я не могу себе представить, как эта система будет выглядеть с мультитенантным приложением, когда 200 ботов просматривают 100 страниц каждый одновременно.

Laravel отлично подходит для простых приложений. Lumen терпим, если вам не нужно делать ничего особенного, что потребовало бы ерунды промежуточного программного обеспечения (IE, нет многопользовательских приложений и пользовательских доменов и т. Д.);

Однако мне никогда не нравится начинать с чего-то, что может связывать и вызывать загрузку 300 мс для сообщения "hello world".

Если вы думаете: "Какая разница?"

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

Я обнаружил, что наибольшего прироста скорости с Laravel 4 можно добиться, выбрав правильные драйверы сеанса;

Sessions "driver" file;

Requests per second:    188.07 [#/sec] (mean)
Time per request:       26.586 [ms] (mean)
Time per request:       5.317 [ms] (mean, across all concurrent requests)


Session "driver" database;

Requests per second:    41.12 [#/sec] (mean)
Time per request:       121.604 [ms] (mean)
Time per request:       24.321 [ms] (mean, across all concurrent requests)

надеюсь, это поможет

Из моего конкурса Hello World, какой из них Laravel? Думаю, вы можете догадаться. Я использовал контейнер докеров для теста, и вот результаты

Чтобы сделать http-ответ «Hello World»:

• Golang с обработчиком журналов stdout: 6000 rps
• SpringBoot с обработчиком журналов, стандартный вывод: 3600 об / с
• Laravel 5 с отключенным журналом: 230 оборотов в секунду

Я довольно часто использую Laravel и просто не верю цифрам, которые он мне сообщает, потому что сквозной рендеринг, измеренный моим браузером, показывает НИЖЕ общее время от запроса до готовности.

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

Я не знаю, как вычисляются эти числа, но они не подтверждаются наблюдениями или инструментами браузера, такими как Firebug ...

Laravel на самом деле не так уж и медленен, особенно при оптимизации. Однако он требует памяти. Даже тяжелая CMS, такая как Drupal, которая очень медленная, по-видимому, занимает около 1/3 объема памяти, занимаемого простым запросом Laravel.

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

Я знаю, что это старый вопрос, но все изменилось. Laravel не такой медленный. Как уже упоминалось, синхронизированные папки работают медленно. Однако в Windows 10 я не смог использовать rsync. Я пробовал и то cygwinи другое minGW. Похоже rsyncнесовместимо с git for windowsрусской версией ssh.

Вот что у меня сработало: NFS .

Vagrant docs говорит:

Папки NFS не работают на хостах Windows. Vagrant проигнорирует ваш запрос на синхронизацию папок NFS в Windows.

Это уже не так. Сейчас мы можем использовать vagrant-winnfsd плагин . Установить действительно просто:

1. Выполнить vagrant plugin install vagrant-winnfsd
2. Измените в вашем Vagrantfile:config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. Добавить в Vagrantfile:config.vm.network "private_network", type: "dhcp"

Это все, что мне нужно для NFSработы. Время отклика Laravel для меня уменьшилось с 500 мс до 100 мс.

Я столкнулся 1.40s при работе с чистым ларавелом в области разработки!

проблема заключалась в использовании: php artisan serve для запуска веб-сервера

когда я использовал веб-сервер apache (или NGINX) вместо этого для того же кода, я получил его 153ms

Поскольку никто об этом не упомянул, я обнаружил, что отладчик xdebug значительно увеличил время. Я обслужил базовую динамическую страницу «Hello World, время 2020-01-01T01: 01: 01.010101» и использовал ее в моем httpd.conf для определения времени запроса:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" **%T/%D**" combined

% T - время обслуживания в секундах,% D - время в микросекундах. С этим в моем php.ini:

[XDebug]
xdebug.remote_autostart = 1
xdebug.remote_enable = 1

У меня время отклика составляло около 770 мс, но когда оба параметра были установлены на 0, чтобы отключить их, оно мгновенно подскочило до 160 мс. Выполнение обоих из них снизило время до 120 мс:

php artisan route:cache
php artisan config:cache

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

В качестве примечания, как ни странно, перемещение сайта с моего SSD на вращающийся жесткий диск не дало никаких преимуществ в производительности, что для меня очень странно, но я полагаю, что он может быть кеширован, я использую Windows 10 с XAMPP.

Laravel работает медленно, потому что в большинстве случаев использование PHP для веб-страниц происходит медленно.

В Laravel вся структура перестраивается при каждом вызове - вот почему все страницы указывают на index.php. Поскольку весь фреймворк представляет собой сценарии PHP, все они должны каждый раз проходить через интерпретатор PHP. Чем больше рамка, тем больше времени на это потребуется.

Сравните это с «серверной средой» (например, tomcat), где сервер запускает код инициализации один раз, и в конечном итоге все страницы будут в собственном коде (после JIT).

В качестве справочного примера, при использовании того же оборудования, ОС и т. Д. Простой 'hello world' с использованием JSP на этом оборудовании - 3000 об / с, тот же hello world на laravel - 51 об / с.

Самый простой способ проверить накладные расходы фреймворка и результирующее максимальное количество запросов в секунду на ядро ​​- использовать Apache AB и значение параллелизма, равное 1, с простым динамическим приветственным миром (чтобы избежать статического кэширования страниц).