Tôi mới bắt đầu sử dụng Laravel. Tôi hầu như chưa viết được bất kỳ mã nào, nhưng các trang của tôi mất gần một giây để tải!
Điều này khiến tôi hơi sốc khi các ứng dụng không có khuôn khổ và ứng dụng NodeJS của tôi mất ~ 2ms. Laravel đang làm gì? Đây không phải là hành vi bình thường phải không? Nó có cần một số tinh chỉnh không?
Câu trả lời:
Laravel là không thực sự là chậm. 500-1000ms là vô lý; Tôi đã nhận được nó xuống còn 20ms ở chế độ gỡ lỗi.
Vấn đề là Vagrant / VirtualBox + các thư mục chia sẻ. Tôi không nhận ra rằng họ đã tạo ra một thành công như vậy. Tôi đoán vì Laravel có quá nhiều phụ thuộc (tải ~ 280 tệp) và mỗi tệp đó đọc rất chậm, nên nó cộng lại rất nhanh.
kreeves đã chỉ cho tôi đúng hướng, bài đăng trên blog này mô tả một tính năng mới trong Vagrant 1.5 cho phép bạn rsync các tệp của mình vào VM thay vì sử dụng thư mục được chia sẻ.
Không có ứng dụng khách rsync gốc trên Windows, vì vậy bạn sẽ phải sử dụng cygwin . Cài đặt nó và đảm bảo đã tắt Net / rsync. Thêm C:\cygwin64\binvào đường dẫn của bạn. [Hoặc bạn có thể cài đặt nó trên Win10 / Bash]
Vagrant giới thiệu tính năng mới . Tôi đang sử dụng Puphet, vì vậy Vagrantfile của tôi trông hơi buồn cười. Tôi đã phải chỉnh sửa nó để trông như thế này:
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
Khi bạn đã thiết lập xong, hãy thử vagrant up. Nếu mọi thứ suôn sẻ, máy của bạn sẽ khởi động và nó sẽ sao chép tất cả các tệp. Bạn sẽ cần chạy vagrant rsync-autotrong một thiết bị đầu cuối để giữ cho các tệp được cập nhật. Bạn sẽ phải trả một chút thời gian chờ đợi, nhưng để tải trang nhanh hơn 30 lần, điều đó đáng giá!
Nếu bạn đang sử dụng PhpStorm, tính năng tự động tải lên của nó hoạt động tốt hơn rsync. PhpStorm tạo ra rất nhiều tệp tạm thời có thể làm tăng tốc các trình theo dõi tệp, nhưng nếu bạn để nó tự xử lý các tệp tải lên, nó sẽ hoạt động tốt.
Một lựa chọn nữa là sử dụng lsyncd . Tôi đã thành công lớn khi sử dụng tính năng này trên máy chủ Ubuntu -> FreeBSD guest. Tôi chưa thử nó trên máy chủ Windows.
artisan optimizeđể tăng nhẹ. Phần còn lại chủ yếu là cách bạn thiết kế ứng dụng của mình, tôi nghĩ. Cài đặt barryvdh/laravel-debugbarvà tìm kiếm bất kỳ sự chậm chạp nào.
Để giúp bạn giải quyết vấn đề của bạn, tôi đã tìm thấy blog này nói về việc tối ưu hóa sản xuất laravel. Hầu hết những gì bạn cần làm để làm cho ứng dụng của bạn trở nên nhanh chóng bây giờ sẽ nằm trong tay về mức độ hiệu quả của mã, dung lượng mạng, CDN, bộ nhớ đệm, cơ sở dữ liệu.
Bây giờ tôi sẽ nói về vấn đề:
Laravel chậm ra khỏi hộp. Có nhiều cách để tối ưu hóa nó. Bạn cũng có tùy chọn sử dụng bộ nhớ đệm trong mã của mình, cải thiện máy chủ của bạn, yadda yadda yadda. Nhưng cuối cùng thì Laravel vẫn chậm.
Laravel sử dụng rất nhiều thư viện symfony và như bạn có thể thấy trong các điểm chuẩn của techempower , symfony xếp hạng rất thấp (cuối cùng phải nói là ít nhất). Bạn thậm chí có thể tìm thấy điểm chuẩn laravel gần như ở cuối.
Rất nhiều quá trình tải tự động đang diễn ra trong nền, những thứ bạn thậm chí có thể không cần sẽ được tải. Về mặt kỹ thuật, vì laravel dễ sử dụng, nó giúp bạn xây dựng ứng dụng nhanh, nhưng nó cũng làm cho nó chậm đi.
Nhưng tôi không nói Laravel là xấu, nó rất tuyệt , tuyệt vời ở rất nhiều thứ. Nhưng nếu bạn mong đợi lượng truy cập tăng cao, bạn sẽ cần nhiều phần cứng hơn chỉ để xử lý các yêu cầu. Nó sẽ khiến bạn tốn kém hơn rất nhiều. Nhưng nếu bạn là người giàu có thì bạn có thể đạt được bất cứ điều gì với Laravel. : D
Sự đánh đổi thông thường:
Easy = Slow, Hard = Fast
Tôi sẽ coi C hoặc Java có đường cong học tập khó và khả năng bảo trì khó nhưng nó xếp hạng rất cao trong các khuôn khổ web.
Mặc dù không quá liên quan. Tôi chỉ đang cố gắng chứng minh quan điểm của easy = slow:
Ruby có danh tiếng rất tốt về khả năng bảo trì và sự dễ dàng để học nó nhưng nó cũng được coi là chậm nhất trong số python và php như được hiển thị ở đây .
Có - Laravel thực sự rất chậm. Tôi đã xây dựng một ứng dụng POC vì lợi ích này. Bộ định tuyến đơn giản, có biểu mẫu đăng nhập. Tôi chỉ có thể nhận được 60 RPS với 10 kết nối đồng thời trên một máy chủ đại dương kỹ thuật số 20 đô la (vài GB ram);
Thiết lập:
2gb RAM
Php7.0
apache2.4
mysql 5.7
memcached server (for laravel session)
Tôi đã chạy tối ưu hóa, tự động tải kết xuất trình soạn nhạc, v.v. và nó thực sự đã hạ RPS xuống 43-ish .
Vấn đề là ứng dụng phản hồi trong 200-400ms. Tôi đã chạy kiểm tra AB từ máy cục bộ đã bật laravel (tức là không thông qua lưu lượng truy cập web); và tôi chỉ nhận được 112 RPS; với thời gian phản hồi nhanh hơn 200ms với mức trung bình là 300ms.
Tương tự, tôi đã thử nghiệm ứng dụng PHP Native sản xuất của mình chạy vài triệu yêu cầu mỗi ngày trên AWS t2.medium (x3, cân bằng tải). Khi tôi AB với 25 kết nối đồng thời từ máy cục bộ của mình tới máy đó qua web, thông qua ELB, tôi nhận được khoảng 1200 RPS. Sự khác biệt rất lớn trên máy có tải so với trang "đăng nhập" laravel.
Đây là các trang có Phiên (bộ đệm đàn hồi / memcached), tra cứu Live DB (truy vấn được lưu trong bộ nhớ cache qua bộ nhớ đệm), Nội dung được kéo qua CDN, v.v., v.v.
Những gì tôi có thể nói, laravel dính khoảng 200-300ms tải trên mọi thứ. Xét cho cùng thì cũng tốt cho các khung nhìn PHP Generated, kiểu trễ đó có thể chấp nhận được khi tải. Tuy nhiên, đối với các khung nhìn PHP sử dụng Ajax / JS để xử lý các cập nhật nhỏ, nó bắt đầu cảm thấy chậm chạp.
Tôi không thể tưởng tượng hệ thống này sẽ như thế nào với một ứng dụng nhiều người thuê trong khi 200 bot thu thập thông tin 100 trang mỗi người cùng một lúc.
Laravel rất tuyệt vời cho các ứng dụng đơn giản. Lumen có thể chấp nhận được nếu bạn không cần phải làm bất cứ điều gì yêu cầu vô nghĩa phần mềm trung gian (IE, không có ứng dụng nhiều người thuê và miền tùy chỉnh, v.v.);
Tuy nhiên, tôi không bao giờ thích bắt đầu với thứ gì đó có thể ràng buộc và gây ra tải 300ms cho một bài đăng "hello world".
Nếu bạn đang nghĩ "Ai quan tâm?"
.. Viết một tìm kiếm dự đoán dựa trên các truy vấn nhanh để trả lời các đề xuất tự động hoàn thành trên một vài trăm nghìn kết quả. Độ trễ 200-300ms đó sẽ khiến người dùng của bạn hoàn toàn mất trí.
Tôi thấy rằng mức tăng tốc độ lớn nhất với Laravel 4 mà bạn có thể đạt được khi chọn các trình điều khiển phiên phù hợp;
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)
Hy vọng điều đó sẽ giúp
Từ cuộc thi Hello World của tôi, Laravel là cái nào? Tôi nghĩ bạn có thể đoán được. Tôi đã sử dụng vùng chứa docker để kiểm tra và đây là kết quả
Để trả lời http "Hello World":
Tôi sử dụng Laravel khá nhiều và tôi chỉ đơn giản là không tin những con số mà nó cho tôi biết bởi vì kết xuất end-to-end như được đo bằng trình duyệt của tôi cho thấy LOWER tổng thời gian từ yêu cầu đến sẵn sàng.
Hơn nữa, tôi nhận được các con số cao hơn một chút trên máy của tôi tại nơi làm việc, điều này thực thi trang nhanh hơn đáng kể so với máy của tôi ở nhà.
Tôi không biết những con số đó được tính toán như thế nào, nhưng chúng không được chứng thực bằng quan sát hoặc các công cụ trình duyệt như Firebug ...
Laravel không thực sự chậm, đặc biệt là khi được tối ưu hóa. Tuy nhiên, nó là bộ nhớ đói. Ngay cả một CMS nặng như Drupal vốn rất chậm, dường như có khoảng 1/3 dấu vết bộ nhớ của một yêu cầu Laravel xương trần.
Do đó, để chạy Laravel trong sản xuất, tôi sẽ triển khai tới các máy chủ được tối ưu hóa bộ nhớ trước các máy chủ được tối ưu hóa CPU.
php artisan optimizehay chúng ta có thể làm gì nhiều hơn?
Tôi biết đây là một câu hỏi hơi cũ, nhưng mọi thứ đã thay đổi. Laravel không chậm như vậy. Như đã đề cập, các thư mục được đồng bộ hóa rất chậm. Tuy nhiên, trên Windows 10, tôi không thể sử dụng rsync. Tôi đã thử cả hai cygwinvà minGW. Có vẻ như rsynckhông tương thích với git for windowsphiên bản của ssh.
Đây là những gì đã làm việc cho tôi: NFS .
Tài liệu Vagrant nói:
Các thư mục NFS không hoạt động trên máy chủ Windows. Vagrant sẽ bỏ qua yêu cầu của bạn đối với các thư mục được đồng bộ hóa NFS trên Windows.
Điều này không còn đúng nữa. Chúng ta có thể sử dụng vagrant-winnfsd plugin ngày nay. Nó thực sự đơn giản để cài đặt:
vagrant plugin install vagrant-winnfsdVagrantfile:config.vm.synced_folder ".", "/vagrant", type: "nfs"Vagrantfile:config.vm.network "private_network", type: "dhcp"Đó là tất cả những gì tôi cần để làm NFSviệc. Đối với tôi, thời gian phản hồi của Laravel giảm từ 500ms xuống 100ms.
Vì không ai khác đề cập đến nó, tôi thấy rằng trình gỡ lỗi xdebug đã tăng đáng kể thời gian. Tôi đã phục vụ trang động cơ bản "Xin chào Thế giới, thời gian là 2020-01-01T01: 01: 01.010101" và sử dụng trang này trong httpd.conf của mình để xác định thời gian yêu cầu:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" **%T/%D**" combined
% T là thời gian giao bóng tính bằng giây,% D là thời gian tính bằng micro giây. Với điều này trong php.ini của tôi:
[XDebug]
xdebug.remote_autostart = 1
xdebug.remote_enable = 1
Tôi đã nhận được khoảng 770ms thời gian phản hồi, nhưng với cả hai thời gian đó được đặt thành 0 để tắt chúng, nó đã tăng lên 160ms ngay lập tức. Chạy cả hai điều này đã làm giảm nó xuống 120ms:
php artisan route:cache
php artisan config:cache
Nhược điểm là nếu tôi thực hiện các thay đổi cấu hình hoặc định tuyến, tôi sẽ cần phải lưu trữ lại chúng, điều này gây khó chịu.
Như một chú thích phụ, thật kỳ lạ, việc di chuyển trang web từ SSD của tôi sang ổ cứng HDD quay không mang lại lợi ích về hiệu suất, điều này thật kỳ lạ đối với tôi, nhưng tôi cho rằng nó có thể được lưu trong bộ nhớ cache, tôi đang sử dụng Windows 10 với XAMPP.
Laravel chậm, vì trong hầu hết các trường hợp, sử dụng PHP cho các trang web là chậm.
Với Laravel, toàn bộ khung công tác được xây dựng lại trên mọi lệnh gọi - đó là lý do tại sao tất cả các trang đều trỏ đến index.php. Vì toàn bộ khung công tác là các tập lệnh PHP, tất cả chúng đều cần phải thông qua trình thông dịch PHP - mỗi lần. Khuôn khổ càng lớn, thời gian này càng lâu.
Ngược lại điều này với "môi trường máy chủ" (ví dụ: tomcat) nơi máy chủ chạy mã khởi tạo một lần và cuối cùng tất cả các trang sẽ ở mã gốc (sau JIT).
Như một ví dụ tham khảo, sử dụng cùng một phần cứng, hệ điều hành, v.v., một 'hello world' đơn giản sử dụng JSP trên phần cứng này là 3000 rps, hello world tương tự trên laravel là 51 rps.
Cách dễ nhất để kiểm tra tổng chi phí của khuôn khổ và kết quả là RPS tối đa trên mỗi lõi, là sử dụng Apache AB và giá trị đồng thời là 1, với 'hello world' đơn giản là động (để tránh bộ đệm trang tĩnh).
php artisan optimize --force