Czy Laravel naprawdę jest tak wolny?

Właśnie zacząłem używać Laravel. Prawie nie napisałem żadnego kodu, ale ładowanie moich stron trwa prawie sekundę!

Jest to dla mnie trochę szokujące, gdy moje aplikacje bez frameworka i aplikacje NodeJS zajmują ~ 2 ms. Co robi Laravel? To nie jest normalne zachowanie, prawda? Czy to wymaga dopracowania?

Laravel jest nie faktycznie , że powolny. 500-1000 ms to absurd; Zmniejszyłem to do 20 ms w trybie debugowania.

Problem dotyczył folderów współdzielonych Vagrant / VirtualBox +. Nie zdawałem sobie sprawy, że otrzymali taki hit wydajnościowy. Wydaje mi się, że ponieważ Laravel ma tak wiele zależności (ładuje ~ 280 plików) i każdy z tych plików odczytuje wolno, sumuje się naprawdę szybko.

kreeves wskazał mi właściwy kierunek, ten wpis na blogu opisuje nową funkcję w Vagrant 1.5, która pozwala na rsynchronizację plików z maszyną wirtualną zamiast korzystania z folderu współdzielonego.

W systemie Windows nie ma natywnego klienta rsync, więc będziesz musiał użyć cygwin . Zainstaluj go i pamiętaj o zaznaczeniu opcji Net / rsync. Dodaj C:\cygwin64\bindo swoich ścieżek. [Lub możesz zainstalować go na Win10 / Bash]

Vagrant przedstawia nową funkcję . Używam Puphet, więc mój plik Vagrantfile wygląda trochę śmiesznie. Musiałem to poprawić, aby wyglądało tak:

  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

Gdy wszystko będzie gotowe, spróbuj vagrant up. Jeśli wszystko pójdzie gładko, komputer powinien się uruchomić i skopiować wszystkie pliki. Aby vagrant rsync-autopliki były aktualne, musisz uruchomić terminal. Zapłacisz trochę za opóźnienie, ale przy 30-krotnie szybszym ładowaniu strony warto!

Jeśli używasz PhpStorm, jego funkcja automatycznego przesyłania działa nawet lepiej niż rsync. PhpStorm tworzy wiele plików tymczasowych, które mogą spowodować błąd obserwatorów plików, ale jeśli pozwolisz mu samodzielnie obsłużyć przesyłanie, działa dobrze.

Jeszcze jedną opcją jest użycie lsyncd . Odniosłem wielki sukces, używając tego na hoście Ubuntu -> gość FreeBSD. Nie próbowałem jeszcze tego na hoście Windows.

Aby pomóc Ci rozwiązać Twój problem, znalazłem ten blog, który mówi o optymalizacji produkcji laravel. Większość tego, co musisz zrobić, aby Twoja aplikacja była szybka, zależy teraz od wydajności kodu, przepustowości sieci, CDN, pamięci podręcznej, bazy danych.

Teraz opowiem o problemie:

Laravel jest powolny po wyjęciu z pudełka. Istnieją sposoby, aby to zoptymalizować. Masz również możliwość korzystania z buforowania w swoim kodzie, ulepszając swój serwer, yadda yadda yadda. Ale ostatecznie Laravel jest nadal powolny.

Laravel używa wielu bibliotek symfony i jak widać w testach porównawczych techempower , symfony plasuje się bardzo nisko (co najmniej). Można nawet stwierdzić, że benchmark laravela znajduje się prawie na dole.

W tle dzieje się dużo automatycznego ładowania, a rzeczy, których możesz nawet nie potrzebować, są ładowane. Tak więc technicznie, ponieważ laravel jest łatwy w użyciu, pomaga w szybkim tworzeniu aplikacji, a także spowalnia.

Ale nie mówię, że Laravel jest zły, jest świetny , świetny w wielu rzeczach. Ale jeśli spodziewasz się dużego wzrostu ruchu, będziesz potrzebować znacznie więcej sprzętu tylko do obsługi żądań. Kosztowałoby to dużo więcej. Ale jeśli jesteś obrzydliwie bogaty, z Laravelem możesz osiągnąć wszystko. :RE

Zwykły kompromis:

 Easy = Slow, Hard = Fast

Uważam, że C lub Java mają trudną krzywą uczenia się i trudną konserwację, ale zajmują bardzo wysokie miejsce w frameworkach internetowych.

Choć niezbyt spokrewnione. Próbuję tylko udowodnić, że easy = slow:

Ruby ma bardzo dobrą reputację pod względem łatwości utrzymania i łatwości w nauce, ale jest również uważany za najwolniejszy wśród Pythona i PHP, jak pokazano tutaj .

Tak - Laravel JEST naprawdę powolny. Z tego powodu stworzyłem aplikację POC. Prosty router z formularzem logowania. Mogłem uzyskać tylko 60 RPS przy 10 jednoczesnych połączeniach na cyfrowym serwerze oceanicznym za 20 USD (kilka GB pamięci RAM);

Ustawiać:

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

Przeprowadziłem optymalizacje, automatyczne ładowanie zrzutu kompozytora itp., I faktycznie obniżyłem RPS do 43-ish .

Problem polega na tym, że aplikacja odpowiada w 200-400 ms. Uruchomiłem test AB z lokalnego komputera, na którym laravel był włączony (tj. Nie przez ruch internetowy); i mam tylko 112 RPS; z 200 ms szybszym czasem odpowiedzi ze średnią 300 ms.

Dla porównania przetestowałem moją produkcyjną aplikację natywną PHP obsługującą kilka milionów żądań dziennie na AWS t2.medium (x3, zrównoważone obciążenie). Kiedy miałem 25 jednoczesnych połączeń z mojego lokalnego komputera do tego przez Internet, przez ELB, otrzymałem około 1200 RPS. Ogromna różnica między maszyną z obciążeniem a stroną "logowania" laravel.

Są to strony z sesjami (flexibleache / memcached), wyszukiwania Live DB (zapytania w pamięci podręcznej przez memcached), zasoby ściągnięte przez CDN itp., Itd.

Co mogę powiedzieć, laravel wytrzymuje około 200-300 ms obciążenia. W końcu jest to dobre dla widoków generowanych przez PHP, w końcu ten typ opóźnienia jest tolerowany podczas ładowania. Jednak w przypadku widoków PHP, które używają Ajax / JS do obsługi małych aktualizacji, zaczyna się to wydawać powolne.

Nie mogę sobie wyobrazić, jak ten system wyglądałby z aplikacją obsługującą wiele dzierżawców, podczas gdy 200 botów indeksuje 100 stron jednocześnie.

Laravel doskonale nadaje się do prostych aplikacji. Lumen jest tolerowany, jeśli nie musisz robić niczego wymyślnego, co wymagałoby bzdury z oprogramowaniem pośredniczącym (IE, brak aplikacji dla wielu dzierżawców i domen niestandardowych itp.);

Jednak nigdy nie lubię zaczynać od czegoś, co może wiązać się i powodować 300 ms obciążenia dla posta „hello world”.

Jeśli myślisz „Kogo to obchodzi?”

.. Napisz wyszukiwanie predykcyjne, które opiera się na szybkich zapytaniach odpowiadających na sugestie autouzupełniania w kilkuset tysiącach wyników. To opóźnienie 200-300 ms doprowadzi twoich użytkowników do absolutnego szaleństwa.

Odkryłem, że największy wzrost szybkości dzięki Laravel 4 można osiągnąć wybierając odpowiednie sterowniki sesyjne;

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)

Mam nadzieję, że to pomoże

Z mojego konkursu Hello World, który to Laravel? Myślę, że możesz zgadnąć. Do testu użyłem kontenera docker i oto wyniki

Aby wysłać odpowiedź http „Hello World”:

• Golang z obsługą logów stdout: 6000 rps
• SpringBoot z obsługą logów: 3600 obr / s
• Laravel 5 z wylogowaniem: 230 rps

Używam Laravel dość często i po prostu nie wierzę liczbom, które mi mówi, ponieważ renderowanie od końca do końca mierzone przez moją przeglądarkę pokazuje NIŻSZY całkowity czas od żądania do gotowości.

Co więcej, uzyskuję nieco wyższe liczby na moim komputerze w pracy, co powoduje, że strona jest wykonywana zauważalnie szybciej niż mój komputer w domu.

Nie wiem, jak te liczby są obliczane, ale nie są potwierdzane przez obserwacje ani narzędzia przeglądarki, takie jak Firebug ...

Laravel nie jest wcale taki wolny, zwłaszcza po optymalizacji. Jest jednak głodny pamięci. Nawet ciężki CMS, taki jak Drupal, który jest bardzo powolny, wydaje się mieć około 1/3 miejsca w pamięci żądania gołego kości Laravel.

W związku z tym, aby uruchomić Laravel w środowisku produkcyjnym, wdrożyłbym je na serwerach zoptymalizowanych pod kątem pamięci przed serwerami zoptymalizowanymi pod kątem procesora.

Wiem, że to trochę stare pytanie, ale wszystko się zmieniło. Laravel nie jest taki powolny. Jak już wspomniano, synchronizowane foldery działają wolno. Jednak w systemie Windows 10 nie mogłem użyć rsync. Próbowałem obu cygwini minGW. Wygląda na to, że rsyncjest niezgodny z git for windowswersją programu ssh.

Oto, co zadziałało dla mnie: NFS .

Vagrant Docs mówi:

Foldery NFS nie działają na hostach Windows. Vagrant zignoruje Twoje żądanie dotyczące synchronizowanych folderów NFS w systemie Windows.

To już nie jest prawda. Obecnie możemy korzystać z vagrant-winnfsd wtyczki . Instalacja jest naprawdę prosta:

1. Wykonać vagrant plugin install vagrant-winnfsd
2. Zmień swoje Vagrantfile:config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. Dodaj do Vagrantfile:config.vm.network "private_network", type: "dhcp"

To wszystko, czego potrzebowałem do NFSpracy. Czas odpowiedzi Laravel zmniejszył się dla mnie z 500 ms do 100 ms.

Zmierzyłem się 1.40spodczas pracy z czystym laravelem w obszarze deweloperskim!

problem polegał na użyciu: php artisan servedo uruchomienia serwera WWW

kiedy zamiast tego użyłem serwera WWW Apache (lub NGINX) dla tego samego kodu, do którego go sprowadziłem 153ms

Ponieważ nikt inny o tym nie wspomniał, stwierdziłem, że debugger xdebug radykalnie wydłużył czas. Obsłużyłem podstawową dynamiczną stronę „Hello World, the time is 2020-01-01T01: 01: 01.010101” i użyłem tego w moim httpd.conf do określenia czasu żądania:

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

% T to czas serwowania w sekundach,% D to czas w mikrosekundach. Z tym w moim php.ini:

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

Czas odpowiedzi wynosił około 770 ms, ale przy obu ustawionych na 0, aby je wyłączyć, natychmiast przeskoczył do 160 ms. Uruchomienie obu zmniejszyło czas do 120 ms:

php artisan route:cache
php artisan config:cache

Wadą jest to, że gdybym wprowadził zmiany w konfiguracji lub trasie, musiałbym ponownie je buforować, co jest denerwujące.

Na marginesie, co dziwne, przeniesienie witryny z mojego dysku SSD na obracający się dysk twardy nie zapewniło żadnych korzyści w zakresie wydajności, co jest dla mnie bardzo dziwne, ale przypuszczam, że może być buforowane, jestem na Windows 10 z XAMPP.

Laravel jest powolny, ponieważ w większości przypadków używanie PHP dla stron internetowych jest powolne.

W Laravel cały framework jest przebudowywany przy każdym wywołaniu - dlatego wszystkie strony wskazują index.php. Ponieważ cały framework to skrypty PHP, wszystkie one muszą przejść przez interpreter PHP - za każdym razem. Im większa rama, tym dłużej to trwa.

Porównaj to ze „środowiskiem serwera” (np. Tomcat), w którym serwer uruchamia kod inicjalizacyjny raz i ostatecznie wszystkie strony będą w kodzie natywnym (po JIT).

Jako przykład odniesienia, używając tego samego sprzętu, systemu operacyjnego itp., Prosty „hello world” przy użyciu JSP na tym sprzęcie to 3000 rps, ten sam hello world na laravel to 51 rps.

Najłatwiejszym sposobem przetestowania obciążenia struktury i wynikającego z tego maksymalnego RPS na rdzeń jest użycie Apache AB i wartości współbieżności 1, z prostym „witaj świat”, który jest dynamiczny (aby uniknąć statycznego buforowania strony).