Tại sao một trang web ASP.Net tải chậm? [đóng cửa]

Thông thường, tôi đã truy cập nhiều trang web .aspx yêu cầu thời gian tải đáng kể cho mỗi trang.

Là kinh nghiệm của tôi là duy nhất?

Nếu không, tại sao một trang web ASP.Net có thể tải chậm?

Chỉnh sửa: Bây giờ là khoảng 7 năm sau (29/12/2017). Tin tốt là tôi không thấy vấn đề này nhiều nữa, có thể do Google bắt đầu xử phạt các trang web tải quá chậm. Bây giờ tôi sử dụng ASP.NET MVC với kết quả tốt, hiện đang chạy trên máy chủ ảo riêng của Vultr (Azure quá chậm khi chúng tôi dùng thử.) Một số tội phạm tồi tệ nhất tôi thấy bây giờ là các hệ thống CMS như Wordpress và Drupal, có thể đang chạy trên phần cứng quá chậm hoặc không được cung cấp cho lưu lượng truy cập mà trang web nhận được. -HK1

Năm khả năng tôi có thể nghĩ đến (ngoài một số kỹ thuật bộ nhớ đệm nâng cao và như vậy):

• Kích thước không đúng của máy chủ web cho ASP.NET (nghĩa là một máy chủ có kích thước cho ASP cổ điển sẽ ổn)

• Quên để xóa <compilation debug="true"/> khỏi web.config và nhận ít hơn mã tối ưu .

• JIT cho chuyến thăm đầu tiên

• Mã được nhúng trong trang (trái ngược với mã được biên dịch phía sau) yêu cầu biên dịch trước và ngoài JIT.

• ViewState (đối với ASP.NET WebForms) trở nên quá lớn .

Rõ ràng đây có thể là câu trả lời xứng đáng.

Có thể là nhiều yếu tố chơi. Trang web bạn đang sử dụng chính thời điểm này được xây dựng trên .NET và nó thường rất nhanh (trừ thời gian ngừng hoạt động / thời gian bảo trì).

Các nhà phát triển của những trang web bạn truy cập có thể đang đẩy hàng tấn dữ liệu đến bạn, hoặc kết nối chậm, hoặc máy chủ quá tải, v.v. v.v ... Nó cũng có thể là nhận thức khi chơi. Ngoài ra, có thể điên javascript khi chơi và bạn đang chạy IE? Hay flash?

Nếu bạn không thực sự biết những gì bạn đang làm, ASP.NET WebForms cho phép bạn tạo một ứng dụng web bằng cách thả các điều khiển vào một biểu mẫu, thậm chí đi xa đến mức che giấu bản chất không trạng thái của http. Nó hoạt động, nhưng kiểu phát triển đó sẽ không bao giờ tạo ra mã hiệu quả, đặc biệt nếu lớp truy cập dữ liệu của bạn liên quan đến các truy vấn được tạo, chọn mọi thứ từ cơ sở dữ liệu sql express không có chỉ mục.

Có rất nhiều trang web asp.net nhanh chóng được phát triển bởi những người hiểu cách các ứng dụng web thực sự hoạt động. Điều đó bao gồm trang web này - nó sử dụng ASP.NET MVC cung cấp nhiều quyền kiểm soát hơn trong việc xử lý các yêu cầu riêng lẻ và không hiển thị phần mở rộng .aspx.

Chỉ cần suy đoán ở đây là tôi đã nhận thấy điều tương tự. Tôi nghi ngờ rằng các trang web .asp có xu hướng (lưu ý từ có xu hướng ) tự lưu trữ trên máy chủ của công ty, trái ngược với lưu trữ tại hoặc trong các trung tâm dữ liệu. Vì vậy, chúng thường chạy trên phần cứng và các kết nối không thực sự được thiết kế cho lưu lượng truy cập web tốc độ cao. Tôi nghi ngờ các trang web điều khiển nhiệt hạch lạnh cũng bị điều này.

Khi một trang web tải (sự kiện application.start), sẽ mất thời gian để tải mọi thứ vào bộ nhớ. Tùy thuộc vào cài đặt IIS, sau khoảng 20-30 phút không hoạt động, nó sẽ hủy tải. Tôi đã không bắt gặp một cách tử tế để giữ cho ứng dụng chạy liên tục mà không cần một số dịch vụ thực hiện GETcứ sau hơn 10 phút.

Một phụ trợ / thiết bị dữ liệu được thiết kế kém có thể làm cho mọi thứ chạy chậm (cho dù máy tính có chạy nhanh như thế nào). Hồ sơ sẽ giúp bạn xác định các vấn đề đang ở đâu.

Bạn chắc chắn đang tưởng tượng điều này. :)

Rất nhiều yếu tố đi kèm với bất kỳ phần mềm nào. Kiến trúc, sự dư thừa của dòng mã, chất lượng của mã, v.v ... Quá nhiều để thậm chí bắt đầu liệt kê.

Bạn có muốn bằng chứng rằng ASP là tốt cho việc sử dụng cấp doanh nghiệp? Chính trang web này (và tất cả các trang web SE) được tạo bằng cách sử dụng ASP.Net - cụ thể là MVC.

Lần cuối cùng trang web này chậm là khi nào? Tôi đã ở đây hơn một năm và chưa bao giờ tôi nhận thấy mọi thứ đang diễn ra mặc dù lượng người dùng khổng lồ của nó.

Các viewstate thực sự có thể làm chậm các postback. Nếu bạn có danh sách thả xuống lớn trên một trang, bạn không nên sử dụng trạng thái xem trên chúng.

Khung nhìn cho phép bạn giả vờ rằng bạn đang làm việc trên một ứng dụng winforms trạng thái. Điều đó đôi khi có thể khiến bạn gặp rắc rối.

Tất cả những điều trên có khả năng đúng. Yếu tố duy nhất lớn nhất ảnh hưởng đến hiệu suất trong trang web ASP.NET mà tôi đã làm việc là mọi thứ liên quan đến nó đều cũ. Phiên bản .NET framework, các máy chủ, cơ sở hạ tầng cơ sở dữ liệu và bản thân mã đều bị lão hóa xấu.

Tôi nghi ngờ nhiều trang web ASP.NET có xu hướng là các trang web công ty. Những người này không nhận được nhiều tình yêu, vì họ có xu hướng chỉ làm việc . Mọi người không viết lại chúng cho đến khi chúng phải, thường là một thời gian rất dài trên đường.

Tôi biết trang web mà tôi đã làm việc với ASP.NET đã sử dụng đó đã tăng tốc rất lớn chỉ bằng cách chuyển sang phiên bản mới nhất của khung công tác, có các mặc định bộ nhớ cache JITing và bộ nhớ cache hiệu quả hơn nhiều.

Một điều khác mà tôi đã thấy rằng rất nhiều trang web ASP.NET không biết cách chia tỷ lệ đúng. Họ không có thiết lập cân bằng tải thích hợp vì thiết kế trang web của họ hoạt động chính xác với các khu vườn web không phổ biến hoặc được ghi chép tốt trong cộng đồng. Nếu bạn không thiết kế trang web của mình cho các khu vườn web ngay từ đầu, bạn không thể sử dụng cơ chế mở rộng quy mô tích hợp mà IIS có. Cân bằng tải phần mềm với Windows NLB không phổ biến và rất phức tạp để quản lý. .

Cân bằng tải phần cứng với F5 rất tốn kém, nhưng dường như là cơ chế đơn giản và phổ biến nhất để nhân rộng các trang web ASP.NET trong các mạng công ty. Tôi nghĩ trong đám đông nguồn mở, kỳ vọng là bạn xây dựng cân bằng tải ngay từ đầu bằng cách sử dụng các công cụ nguồn mở có sẵn miễn phí, tự động mở rộng dựa trên việc sử dụng. Điều này không phổ biến trong thế giới ASP.NET từ những gì tôi đã thấy.