Tôi đang gặp vấn đề về hiệu năng trên 3.1.0ứng dụng Rails , hiện tại tôi đã thực hiện thay đổi vòm trên các truy vấn của mình bằng AR và vì vậy, các khung nhìn vẫn mất quá nhiều thời gian để hiển thị, tôi đã chia các khung nhìn, các vòng lặp và trên nhiều phần mà được hiển thị linh hoạt bên trong các khung nhìn và bên trong các phần khác.
Vì vậy, đó là một thực tế xấu để có một số lượng lớn các hạt?
Tôi có nên giảm số lượng partials để cải thiện thời gian hiển thị lượt xem không?
Cảm ơn
Câu trả lời:
Tôi biết về việc không có sự khác biệt đáng kể về hiệu suất kết xuất giữa nhiều phần và một chế độ xem khi bạn kết xuất cùng một nội dung.
Rõ ràng, nếu bạn chỉ hiển thị một số hạt trong một số trường hợp và một số khác trong các trường hợp khác, thì việc giảm khối lượng kết xuất của một chế độ xem cụ thể có hiệu quả hơn là bạn có thể đạt được một số tốc độ.
Mặt khác, tôi luôn xem xét các phần trừu tượng hóa nên được sử dụng ít nhất từ 2 nơi khác nhau để biện minh cho sự tồn tại của chúng. Lý do khác để sử dụng các phần là khi bạn muốn hiển thị cùng một chế độ xem nhưng tải các phần khác nhau dựa trên một số logic nghiệp vụ bạn có.
CẬP NHẬT:
Tôi không thể đưa ra một phép đo hoặc một số con số cụ thể về tốc độ kết xuất. Nếu bạn sử dụng một phần trong một khung nhìn, để kết xuất nó, bạn gọi phương thức kết xuất, do đó có một cuộc gọi phương thức thứ hai. Điều này, như tôi đã nói trong câu trả lời của mình, hầu như không có gì nhưng có thể giúp tăng tốc mọi thứ rất ít.
Tuy nhiên tôi chưa bao giờ nghe nói về một dự án khắc phục vấn đề hiệu năng của nó bằng cách loại bỏ các phần. Các phần là một cách tốt để cung cấp một cơ chế tái sử dụng cho các khung nhìn và từ chế độ xem của các lập trình viên, chúng nên được sử dụng cho phạm vi đó. Chúng nên được trừu tượng hóa cho các khái niệm phổ biến trong quan điểm.
Tôi đã làm việc trong một dự án nơi các hạt được sử dụng quá mức. Không phải Rails, nhưng cùng một nguyên tắc MVC. Sử dụng các hạt nhỏ cho mọi thứ bạn có thể tưởng tượng khiến chúng khó tìm thấy khi bạn bắt đầu có hàng tá chúng. Nơi nào bạn sẽ tìm kiếm một đầu vào để được sửa đổi? Theo quan điểm? Trong một phần? Trong đó một phần, có 4 phần cho quan điểm này? ...
Sau một số lần tái cấu trúc cứng, với mỗi lần cập nhật chế độ xem, chúng tôi đã loại bỏ các phần không cần thiết. Họ đã không biến mất hoàn toàn, nhưng những gì còn lại là trừu tượng hóa được xác định rõ cho dự án. Chúng đại diện cho các yếu tố được hiểu rõ (như cây cho một số loại đối tượng hoặc loại danh sách cụ thể) lặp lại ở dạng hoặc dạng khác trên một số khung nhìn. Tôi biết nếu tôi nhìn thấy một cái cây có một phần cho điều đó. Tôi biết khi tôi thấy một số loại danh sách nhất định có một phần cho điều đó. Tôi không săn lùng chúng.
Khả năng đọc mã là điều quan trọng nhất mà người ta có thể làm đối với cơ sở mã phần mềm.
Code readability, đó là tất cả những gì về.
Tôi không đồng ý với cả hai câu trả lời. Tôi đã sao chép và dán mã từ một phần vào vị trí mà nó hiện diện trong chế độ xem một phần và với 500 lần lặp, việc này sẽ mất 600ms thời gian để hiển thị chế độ xem. <% = render xyz%> theo ý kiến của tôi rất bị hỏng.
Ví dụ, tổng thời gian để hiển thị chế độ xem:
Before:
5759.8ms
5804.2ms
5973.6ms
After:
5268.7ms
5201.6ms
5222.4ms
Diff = 5846 - 5231 = 615 ms
Đã chỉnh sửa
Cuối cùng tôi đã hủy kết nối tất cả _partials trong phần _model và giảm xuống ~ 2000ms, tại thời điểm đó tôi đã cố gắng di chuyển một phần _model vào chỉ mục tuy nhiên điều này KHÔNG ảnh hưởng gì đến thời gian kết xuất nên tôi đoán đó là các lệnh gọi được lồng vào nhau Phải không.
Không phải là một anh chàng rails, nhưng Partial Views có thể không phải là vấn đề. Thay vào đó, có vẻ như bạn đang thực hiện một chút CHỌN N + 1. Nhìn vào mọi thứ từ quan điểm của máy chủ DB để đảm bảo bạn không đánh bại nó.
Làm việc trên ứng dụng Rails 4.2 ngay bây giờ trong đó một hành động chậm mất trung bình khoảng 745ms.
Khi tôi loại bỏ mã khỏi các phần tử và đặt nó vào mẫu chính, thời gian cần thiết bây giờ là trung bình dưới 25ms.
Số lượng cuộc gọi để kết xuất các hạt chỉ là 29.
Ngay cả khi bạn không có vấn đề n + 1 và làm tất cả các cơ sở dữ liệu hoạt động trước (nói với CTE đệ quy), các phần tử lồng nhau vẫn rất chậm. Haml và Erb đều nhìn tôi chậm chạp. Trên Rails 5.1.4 Tôi đang thấy một vài phần nghìn giây cho mỗi phần, cộng với các phần không thường xuyên tệ hơn nhiều (có thể tương ứng với bộ sưu tập rác).
Tôi nhận thấy rằng nếu tôi đổi tên một phần trong khi một trong những yêu cầu này đang chạy, tôi ngay lập tức gặp lỗi về cách không tìm thấy tệp. Vì vậy, rõ ràng Rails đang đọc đĩa tắt một phần, lặp lại nó và đánh giá nó cho mỗi lần lặp. Thảo nào nó chậm!
Rất nhiều sự chậm chạp được nhìn thấy trong các hạt lồng nhau chỉ xảy ra trong quá trình phát triển. Chuyển sang sản xuất để kiểm tra.