Câu trả lời:
Dưới đây là danh sách tổng hợp các nguồn cải tiến có thể:
Chung
Bộ nhớ đệm
CompiledQuery.Compile()
đệ quy tránh biên dịch lại các biểu thức truy vấn của bạnOutputCacheAttribute
để lưu các thực thi không cần thiết và hành độngActionResultphương thức tùy chỉnh của bạn nếu cần thiếtRouteNameđể tổ chức các tuyến đường của bạn và sau đó sử dụng nó để tạo các liên kết của bạn và cố gắng không sử dụng phương thức ActionLink dựa trên cây biểu thức.PartialViews, tránh hiển thị nó xxxx lần: nếu cuối cùng bạn gọi cùng một phần 300 lần trong cùng một chế độ xem, có thể có điều gì đó không đúng với điều đó. Giải thích và Điểm chuẩnđịnh tuyến
Sử dụng Url.RouteUrl("User", new { username = "joeuser" })để chỉ định các tuyến đường. ASP.NET MVC Perfomance của Rudi Benkovic
Giải quyết lộ trình bộ đệm bằng cách sử dụng trình trợ giúp UrlHelperCached ASP.NET MVC Perfomance này của Rudi Benkovic
Bảo vệ
DAL
Cân bằng tải
Sử dụng proxy ngược, để phân tán tải khách trên toàn bộ ứng dụng của bạn. (Stack Overflow sử dụng HAProxy ( MSDN ).
Sử dụng Bộ điều khiển không đồng bộ để thực hiện các hành động phụ thuộc vào xử lý tài nguyên bên ngoài.
Phía khách hàng
Cấu hình Toàn cầu
Nếu bạn sử dụng Dao cạo, hãy thêm mã sau vào global.asax.cs của bạn, theo mặc định, Asp.Net MVC hiển thị với công cụ aspx và công cụ dao cạo. Điều này chỉ sử dụng RazorViewEngine.
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
Thêm gzip (nén HTTP) và bộ đệm tĩnh (hình ảnh, css, ...) trong web.config của bạn
<system.webServer>
<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/>
</system.webServer>
<pages buffer="true" enableViewState="false">Gợi ý cơ bản là tuân theo các nguyên tắc REST và các điểm sau đây liên kết một số nguyên tắc này với khung công tác ASP.NET MVC:
Code Climber và mục blog này cung cấp các cách chi tiết để tăng hiệu suất của ứng dụng.
Truy vấn biên dịch sẽ tăng hiệu năng của ứng dụng của bạn, nhưng nó không có gì chung với ASP.NET MVC. Nó sẽ tăng tốc mọi ứng dụng db, vì vậy nó không thực sự về MVC.
Điều này có vẻ rõ ràng, nhưng chạy trang web của bạn ở chế độ Phát hành, không phải chế độ Gỡ lỗi, khi đang sản xuất và cả trong quá trình định hình hiệu suất. Chế độ phát hành nhanh hơn nhiều . Chế độ gỡ lỗi có thể ẩn các vấn đề về hiệu suất trong mã của riêng bạn.
Khi truy cập dữ liệu qua LINQ, hãy dựa vào IQueryable ...
Tại sao nên sử dụng AsQueryable () thay vì List ()?
... và tận dụng một mẫu Kho lưu trữ tốt:
Đang tải Subrecords trong Mẫu lưu trữ
Điều này sẽ tối ưu hóa truy cập dữ liệu để đảm bảo chỉ có dữ liệu cần được tải và khi chỉ cần nó.
Không phải là tối ưu hóa rung chuyển trái đất, nhưng tôi nghĩ rằng tôi muốn ném này ngoài kia - Sử dụng CDN cho jQuery, vv .
Trích dẫn từ chính ScottGu: Microsoft Ajax CDN cho phép bạn cải thiện đáng kể hiệu năng của các ứng dụng ASP.NET Web Forms và ASP.NET MVC sử dụng ASP.NET AJAX hoặc jQuery. Dịch vụ này có sẵn miễn phí, không yêu cầu đăng ký và có thể được sử dụng cho cả mục đích thương mại và phi thương mại.
Chúng tôi thậm chí sử dụng CDN cho các trang web của chúng tôi trong Moss sử dụng jQuery.
Ngoài ra nếu bạn sử dụng NHibernate, bạn có thể bật và thiết lập bộ đệm cấp hai cho các truy vấn và thêm vào phạm vi truy vấn và thời gian chờ. Và có trình hồ sơ kick ass cho EF , L2S và NHibernate - http://hibernatingrhinos.com/products/UberProf . Nó sẽ giúp điều chỉnh các truy vấn của bạn.
Tôi cũng sẽ thêm:
Sử dụng Sprites : Sprites là một điều tuyệt vời để giảm yêu cầu. Bạn hợp nhất tất cả các hình ảnh của bạn thành một hình duy nhất và sử dụng CSS để có được phần tốt của sprite. Microsoft cung cấp một thư viện tốt để làm điều đó: Xem trước tối ưu hóa hình ảnh và Sprite 4 .
Bộ nhớ cache Đối tượng máy chủ của bạn : Nếu bạn có một số danh sách tham chiếu hoặc dữ liệu sẽ hiếm khi thay đổi, bạn có thể lưu chúng vào bộ nhớ thay vì truy vấn cơ sở dữ liệu mỗi lần.
Sử dụng ADO.NET thay vì Entity Framework : EF4 or EF5rất tốt để giảm thời gian phát triển, nhưng sẽ rất khó để tối ưu hóa. Thật đơn giản để tối ưu hóa một thủ tục được lưu trữ hơn Entity Framework. Vì vậy, bạn nên sử dụng thủ tục cửa hàng càng nhiều càng tốt. Dapper cung cấp một cách đơn giản để truy vấn và ánh xạ SQL với hiệu suất rất tốt.
Trang bộ đệm hoặc trang một phần : MVC cung cấp một số bộ lọc dễ dàng cho trang bộ đệm theo một số tham số, vì vậy hãy sử dụng nó.
Giảm các cuộc gọi cơ sở dữ liệu : Bạn có thể tạo một yêu cầu cơ sở dữ liệu duy nhất trả về nhiều đối tượng. Kiểm tra trên trang web của Dapper.
Luôn có một kiến trúc sạch sẽ : Có một kiến trúc n-tiers sạch sẽ, ngay cả trên một dự án nhỏ. Nó sẽ giúp bạn giữ mã của bạn sạch sẽ, và sẽ dễ dàng hơn để tối ưu hóa nó nếu cần.
Bạn có thể xem mẫu này " Mẫu MVC Neos-SDI " sẽ tạo ra một kiến trúc sạch cho bạn với nhiều cải tiến hiệu suất theo mặc định (kiểm tra trang web MvcTemplate ).
Ngoài tất cả các thông tin tuyệt vời về tối ưu hóa ứng dụng của bạn ở phía máy chủ, tôi muốn nói rằng bạn nên xem YSlow . Đó là một nguồn tài nguyên tuyệt vời để cải thiện hiệu suất trang web về phía khách hàng.
Điều này áp dụng cho tất cả các trang web, không chỉ ASP.NET MVC.
Một điều cực kỳ dễ làm là suy nghĩ không đồng bộ khi truy cập dữ liệu bạn muốn cho trang. Cho dù đọc từ dịch vụ web, tệp, cơ sở dữ liệu hoặc thứ gì khác, hãy sử dụng mô hình async càng nhiều càng tốt. Mặc dù nó không nhất thiết phải giúp bất kỳ một trang nào nhanh hơn, nhưng nó sẽ giúp máy chủ của bạn hoạt động tổng thể tốt hơn.
1: Nhận thời gian. Cho đến khi bạn biết sự chậm lại ở đâu, câu hỏi quá rộng để trả lời. Một dự án tôi đang làm có vấn đề chính xác này; Không có đăng nhập để biết những thứ nhất định mất bao lâu; chúng tôi chỉ có thể đoán các phần chậm của ứng dụng cho đến khi chúng tôi thêm thời gian cho dự án.
2: Nếu bạn có các hoạt động liên tiếp, đừng ngại đa luồng nhẹ. ĐẶC BIỆT nếu các hoạt động chặn có liên quan. PLINQ là bạn của bạn ở đây.
3: Tạo trước chế độ xem MVC của bạn khi xuất bản ... Điều đó sẽ giúp với một số 'trang đầu tiên nhấn'
4: Một số tranh luận về thủ tục lưu trữ / lợi thế của tốc độ ADO. Những người khác tranh luận về tốc độ phát triển của EF và sự phân chia rõ ràng hơn về các tầng và mục đích của họ. Tôi đã thấy các thiết kế thực sự chậm khi SQL và các cách giải quyết sử dụng Sprocs / Lượt xem để truy xuất và lưu trữ dữ liệu. Ngoài ra, khó khăn của bạn để kiểm tra tăng lên. Cơ sở mã hiện tại của chúng tôi mà chúng tôi đang chuyển đổi từ ADO sang EF không hoạt động kém hơn (và trong một số trường hợp tốt hơn) so với mô hình cuộn tay cũ.
5: Điều đó nói rằng, Hãy nghĩ về ứng dụng Khởi động. Một phần trong những gì chúng tôi làm để giúp loại bỏ hầu hết các tai ương về hiệu suất của chúng tôi là thêm một phương pháp khởi động đặc biệt. Nó không biên dịch trước bất kỳ truy vấn hay bất cứ điều gì, nhưng nó giúp cho phần lớn việc tải / tạo siêu dữ liệu. Điều này có thể còn quan trọng hơn khi xử lý các mô hình Code First.
6: Như những người khác đã nói, Đừng sử dụng trạng thái Phiên hoặc ViewState nếu có thể. Chúng không nhất thiết phải là tối ưu hóa hiệu suất mà các nhà phát triển nghĩ đến, nhưng một khi bạn bắt đầu viết các ứng dụng web phức tạp hơn, bạn muốn có sự đáp ứng. Phiên trạng thái loại trừ điều này. Hãy tưởng tượng một truy vấn chạy dài. Bạn quyết định mở một cửa sổ mới và thử một cửa sổ ít phức tạp hơn. Vâng, bạn cũng có thể đã đợi với trạng thái phiên, vì máy chủ sẽ đợi cho đến khi yêu cầu đầu tiên được thực hiện trước khi chuyển sang yêu cầu tiếp theo cho phiên đó.
7: Tối thiểu hóa các chuyến đi khứ hồi đến cơ sở dữ liệu. Lưu những thứ bạn thường xuyên sử dụng nhưng sẽ không thực sự thay đổi thành .Net Cache của bạn. Cố gắng để hàng loạt chèn / cập nhật của bạn nếu có thể.
7.1: Tránh mã Truy cập dữ liệu trong chế độ xem Dao cạo của bạn mà không có lý do chính đáng. Tôi sẽ không nói điều này nếu tôi đã không nhìn thấy nó. Họ đã truy cập dữ liệu của họ khi đặt mô hình lại với nhau, tại sao họ không đưa nó vào mô hình?
Chỉ muốn thêm 2 xu của tôi. Cách hiệu quả nhất để tối ưu hóa việc tạo lộ trình URL trong ứng dụng MVC là ... hoàn toàn không tạo ra chúng.
Hầu hết chúng ta ít nhiều đều biết cách tạo URL trong ứng dụng của mình, vì vậy, chỉ cần sử dụng tĩnh Url.Content("~/Blahblah")thay vì Url.Action()hoặc Url.RouteUrl()khi có thể, đánh bại tất cả các phương thức khác gần 20 lần và thậm chí nhiều hơn.
Tái bút Tôi đã chạy một số điểm chuẩn của vài nghìn lần lặp và đăng kết quả lên blog của mình nếu quan tâm.
Trong tiếng kêu của bạn để tối ưu hóa phía máy khách, đừng quên lớp cơ sở dữ liệu. Chúng tôi đã có một ứng dụng đi từ 5 giây để tải tối đa 50 giây qua đêm.
Khi kiểm tra, chúng tôi đã thực hiện một loạt các thay đổi lược đồ. Khi chúng tôi làm mới các số liệu thống kê, nó đột nhiên trở nên nhạy bén như trước.
Sau đây là những việc cần làm
Nếu bạn đang chạy ứng dụng ASP.NET MVC của mình trên Microsoft Azure (IaaS hoặc PaaS), thì hãy thực hiện các thao tác sau ít nhất trước khi triển khai đầu tiên.
Sử dụng phiên bản mới nhất của Thư viện song song tác vụ (TPL) , theo phiên bản .Net. Phải chọn các mô-đun chính xác của TPL cho các mục đích khác nhau.
Tôi đã làm tất cả các câu trả lời ở trên và nó không giải quyết được vấn đề của tôi.
Cuối cùng, tôi đã giải quyết vấn đề tải trang chậm của mình bằng cách đặt PrecompileB BeforePublish trong Publish Profile thành true . Nếu bạn muốn sử dụng msbuild, bạn có thể sử dụng đối số này:
/p:PrecompileBeforePublish=trueNó thực sự giúp ích rất nhiều. Bây giờ MVC ASP.NET của tôi tải nhanh hơn 10 lần.