Я щойно почав використовувати Laravel. Я ще майже не написав жодного коду, але завантаження моїх сторінок займає майже секунду!
Це трохи шокує мене, коли мої безрамкові програми та програми NodeJS займають ~ 2 мс. Що робить Ларавель? Це не нормальна поведінка, чи не так? Чи потрібна якась тонка настройка?
Відповіді:
Laravel насправді не такий повільний. 500-1000 мс - абсурд; Я отримав його до 20 мс у режимі налагодження.
Проблема полягала у спільних папках Vagrant / VirtualBox +. Я не підозрював, що вони зазнали такого вистави. Я думаю, оскільки Laravel має стільки залежностей (завантажує ~ 280 файлів), і кожен з цих файлів читається повільно, і це дуже швидко додається.
kreeves вказав мені у правильному напрямку, цей допис у блозі описує нову функцію у Vagrant 1.5, яка дозволяє вам синхронізувати файли у віртуальній машині, а не використовувати спільну папку.
У Windows немає власного клієнта rsync, тому вам доведеться використовувати cygwin . Встановіть його та переконайтеся, що ви поставили галочку на Net / rsync. Додайте C:\cygwin64\binдо своїх шляхів. [Або ви можете встановити його на Win10 / Bash]
Vagrant представляє нову функцію . Я використовую Puphet, тому мій файл Vagrant виглядає трохи смішно. Мені довелося його налаштувати, щоб виглядати так:
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термінал, щоб підтримувати актуальність файлів. Ви заплатите трохи затримки, але для швидшого завантаження сторінок у 30 разів це варто!
Якщо ви використовуєте PhpStorm, ця функція автоматичного завантаження працює навіть краще, ніж rsync. PhpStorm створює багато тимчасових файлів, які можуть відключити спостерігачів файлів, але якщо ви дозволите йому обробляти завантаження самостійно, це працює чудово.
Ще один варіант - використовувати lsyncd . Я мав великий успіх, використовуючи це на хості Ubuntu -> Гість FreeBSD. Я ще не пробував на хості Windows.
artisan optimizeдля невеликого підвищення. В іншому, я думаю, здебільшого як ви розробляєте свій додаток. Встановіть barryvdh/laravel-debugbarі шукайте будь-яку повільність.
Щоб допомогти вам вирішити вашу проблему, я знайшов цей блог, який розповідає про оптимізацію виробництва ларавелу. Більша частина того, що вам потрібно зробити, щоб зробити ваш додаток швидким, тепер буде в руках того, наскільки ефективним є ваш код, ємність вашої мережі, 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)
Я провів оптимізацію, автозавантаження композитора тощо, і це насправді знизило RPS до 43-ї .
Проблема полягає в тому, що програма реагує за 200-400 мс. Я провів тест AB на локальній машині laravel (тобто не через веб-трафік); і я отримав лише 112 RPS; з 200 мс швидшим часом відгуку в середньому 300 мс.
Порівняно, я протестував свій робочий додаток PHP Native, що запускає кілька мільйонів запитів на день, на AWS t2.medium (x3, збалансоване навантаження). Коли я провів AB одночасно 25 підключень від моєї локальної машини до цього через Інтернет, через ELB, я отримав приблизно 1200 RPS. Величезна різниця на машині з навантаженням порівняно зі сторінкою "входу" в laravel
Це сторінки із сеансами (elasticache / memcached), реальними пошуками БД (кешовані запити через memcached), активами, перетягнутими через CDN тощо тощо тощо.
Що я можу сказати, laravel тримає близько 200-300ms навантаження на речі. Це прекрасно для переглядів, згенерованих PHP, зрештою, такий тип затримки є допустимим при навантаженні. Однак для переглядів PHP, які використовують Ajax / JS для обробки невеликих оновлень, він починає відчувати себе млявим.
Я не уявляю, як би виглядала ця система з додатком для декількох орендарів, тоді як 200 ботів одночасно сканують по 100 сторінок.
Laravel чудово підходить для простих додатків. Lumen терпимий, якщо вам не потрібно робити нічого вигадливого, що вимагало б безглуздя проміжного програмного забезпечення (IE, відсутність додатків для декількох клієнтів, користувацькі домени тощо);
Однак мені ніколи не подобається починати з чогось, що може пов’язати і спричинити навантаження 300 мс для повідомлення "привіт світ".
Якщо ви думаєте "Хто піклується?"
.. Напишіть інтелектуальний пошук, який спирається на швидкі запити, щоб відповісти на пропозиції автозавершення у кількох сотнях тисяч результатів. Це відставання в 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":
Я досить багато використовую Laravel, і я просто не вірю цифрам, які він мені повідомляє, оскільки наскрізний візуалізація, виміряна моїм браузером, показує нижчий загальний час від запиту до готовності.
Крім того, я отримую трохи більші цифри на своїй машині на роботі, що робить сторінку помітно швидше, ніж моя машина вдома.
Я не знаю, як обчислюються ці цифри, але вони не підтверджуються спостереженнями чи інструментами браузера, такими як Firebug ...
Laravel насправді не все так повільно, особливо при оптимізації. Однак пам'ятає пам'ять. Навіть така важка система управління вмістом, як Drupal, яка працює дуже повільно, здається, має приблизно 1/3 розміру пам'яті оголеного запиту Laravel.
Таким чином, щоб запустити Laravel у виробництві, я б розгорнув на серверах, оптимізованих для пам'яті, перед серверами, оптимізованими для процесора.
php artisan optimizeчи ми можемо зробити більше?
Я знаю, що це трохи давнє запитання, але все змінилося. Laravel не такий повільний. Як уже згадувалося, синхронізовані папки працюють повільно. Однак у Windows 10 я не зміг користуватися rsync. Я спробував обидва cygwinі minGW. Здається, rsyncце несумісно з git for windowsросійською версією ssh.
Ось, що мені вдалося : NFS .
Vagrant docs каже:
Папки NFS не працюють на хостах Windows. Vagrant проігнорує ваш запит на синхронізовані папки NFS у Windows.
Це вже неправда. Сьогодні ми можемо використовувати vagrant-winnfsd плагін . Це дуже просто встановити:
vagrant plugin install vagrant-winnfsdVagrantfile:config.vm.synced_folder ".", "/vagrant", type: "nfs"Vagrantfile:config.vm.network "private_network", type: "dhcp"Це все, що мені потрібно для NFSроботи. Час реакції Laravel для мене зменшився з 500 мс до 100 мс.
Оскільки ніхто про це не згадував, я виявив, що налагоджувач 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
Недоліком є те, що якщо я внімую зміни конфігурації або маршруту, мені потрібно буде їх кешувати, що дратує.
Як сторона, як не дивно, переміщення сайту з мого твердотільного накопичувача на обертовий жорсткий диск не забезпечило жодних переваг продуктивності, що для мене надзвичайно дивно, але я думаю, що це, можливо, кешовано, я перебуваю в Windows 10 з XAMPP.
Laravel працює повільно, оскільки в більшості випадків використання PHP для веб-сторінок відбувається повільно.
За допомогою Laravel весь фреймворк перебудовується при кожному виклику - саме тому всі сторінки вказують на index.php. Оскільки весь фреймворк - це PHP-скрипти, кожен раз їм потрібно пройти через інтерпретатор PHP. Чим більший фреймворк, тим довше це триває.
Порівняйте це із "серверним середовищем" (наприклад, tomcat), де сервер запускає код ініціалізації один раз, і врешті-решт усі сторінки будуть у власному коді (після JIT).
Як довідковий приклад, використовуючи одне і те ж обладнання, ОС тощо, простий «привіт світ» із використанням JSP на цьому обладнанні дорівнює 3000 об / с, той самий привіт світ на laravel - 51 об / с.
Найпростіший спосіб перевірити накладні витрати на фреймворк і отриманий в результаті максимальний RPS на ядро - це використовувати Apache AB і значення паралельності 1, з простим динамічним «привіт світом» (щоб уникнути статичного кешування сторінок).
php artisan optimize --force