Xử lý các báo cáo chạy dài

Question

Tôi đang làm việc trên một ứng dụng ASP.net được viết bằng C# với cơ sở dữ liệu Sql Server 2000. Chúng tôi có một số báo cáo PDF mà khách hàng sử dụng cho nhu cầu kinh doanh của họ. Vấn đề là các báo cáo này mất một lúc để tạo (> 3 phút). Điều thường xảy ra là khi người dùng yêu cầu báo cáo thời gian chờ yêu cầu giết chết yêu cầu trước khi máy chủ web có thời gian để kết thúc việc tạo báo cáo, vì vậy người dùng không bao giờ có cơ hội tải xuống tệp. Sau đó, người dùng sẽ làm mới trang và thử lại, bắt đầu toàn bộ quá trình tạo báo cáo và vẫn hết thời gian chờ. (Không, chúng tôi không lưu trữ báo cáo ngay bây giờ; đó là điều tôi đang đẩy mạnh cho ...).

Bạn xử lý các tình huống này như thế nào? Tôi có một ý tưởng trong đầu của tôi trong đó bao gồm việc thực hiện một yêu cầu không đồng bộ để bắt đầu tạo báo cáo và sau đó có một số javascript để định kỳ kiểm tra tình trạng. Khi trạng thái cho biết báo cáo đã hoàn tất, hãy thực hiện yêu cầu riêng cho tệp thực.

Có cách nào đơn giản hơn mà tôi không nhìn thấy không?

Answer 1

Sử dụng hệ thống tệp ở đây có thể là một cược tốt. Có một yêu cầu ngay lập tức trả về một url đến vị trí pdf báo cáo. Sau đó, máy chủ của bạn có thể khởi động quy trình bên ngoài hoặc gửi yêu cầu đến chính nó để thực hiện báo cáo. Máy khách có thể thăm dò ý kiến ​​máy chủ (sử dụng HEAD http) cho tệp PDF tại url được cung cấp. Nếu bạn làm cho tên tập tin của PDF có nguồn gốc từ các tham số báo cáo, hoặc bằng cách sử dụng một băm hoặc trực tiếp đưa các tham số vào tên bạn sẽ nhận được bộ nhớ đệm phía máy chủ ngay lập tức quá.

Answer 2

Điều gì về việc gửi báo cáo qua email tới người dùng. Tất cả các trang asp nên làm là gửi yêu cầu để tạo báo cáo và trả lại một thông báo rằng báo cáo sẽ được gửi qua email sau khi đã kết thúc chạy.

Answer 3

Tôi sẽ xem xét việc tạo báo cáo này bằng cách nào đó ngoại tuyến hơn một chút so với điểm xử lý của chế độ xem.

Giống như tạo hàng đợi để đưa yêu cầu báo cáo vào, xử lý báo cáo từ đó và sau khi hoàn tất, nó có thể gửi tin nhắn cho người dùng.

Có lẽ tôi thậm chí sẽ tạo một Dịch vụ Windows riêng để xử lý hàng đợi.

Cập nhật: gửi cho người dùng có thể gửi email hoặc họ có thể có trang 'báo cáo', nơi họ có thể kiểm tra trạng thái báo cáo của họ và tải xuống nếu họ sẵn sàng.

Answer 4

Người dùng của bạn có thể không chấp nhận phương pháp này, nhưng:

Khi họ yêu cầu báo cáo (bằng cách nhấp chuột vào một nút hoặc một liên kết hoặc bất cứ điều gì), bạn có thể bắt đầu quá trình tạo báo cáo về một chủ đề riêng biệt, và tái hướng người dùng đến trang có nội dung "cảm ơn bạn, báo cáo của bạn sẽ được gửi qua email cho bạn sau vài phút".

Khi chuỗi được tạo xong báo cáo, bạn có thể gửi email trực tiếp cho PDF (có thể sẽ không hoạt động vì kích thước) hoặc lưu báo cáo trên máy chủ và gửi liên kết tới người dùng qua email.

Hoặc, bạn có thể vào IIS và tăng thời gian chờ lên> 3 phút.

Answer 5

Dưới đây là một số điều tôi sẽ làm nếu tôi được trình bày sự cố này:

1- Ngừng những thời gian chờ đó! Chúng là một sự lãng phí tổng số tài nguyên.(mang lại giá trị thời gian chờ của các trang asp)

2- Tập trung tất cả truy cập db vào một điểm, sau đó thu thập số liệu thống kê về báo cáo chạy theo ai và mất bao nhiêu thời gian. Điều tra lý do tại sao phải mất quá lâu, có phải vì báo cáo phức tạp không? phạm vi dữ liệu? tải máy chủ? (bạn thực sự có thể viết rằng trên một tệp .csv trên máy chủ và nhập tệp này định kỳ trong máy chủ sql để phân tích sau).

Cuối cùng, nó sẽ được dễ dàng hơn để bạn có thể "bộ nhớ cache" báo cáo nếu bạn đi qua điểm này truy cập duy nhất (ví dụ, cùng một truy vấn cùng ngày sẽ trở lại cùng PDF được tạo ra trước đó)

3 Tôi biết điều này thực sự không phải là câu hỏi nhưng bạn đã thử lặn vào các truy vấn đó để xem lý do tại sao chúng quá dài để chạy? Có thể điều chỉnh truy vấn?

4- Email/SMS/trên màn hình khi báo cáo sẵn sàng có vẻ tuyệt vời ... nếu người dùng của bạn thường gửi một loạt báo cáo được tạo có thể là một bảng điều khiển nhỏ cho thấy sự tiến triển của hàng đợi "của họ" có thể được xây dựng trong ứng dụng. Một chút điều khiển ajax sẽ làm mới định kỳ trạng thái .. Gợi ý: Nếu bạn sử dụng truy cập db trung tâm đó và bạn có đủ thông tin về những gì sẽ chạy khi nào và tại sao bạn có thể ước tính gần đúng thời gian báo cáo để chạy.

Nếu thời gian phản hồi là nhiệm vụ quan trọng, một số người dùng nhất định có bị giới hạn trong phạm vi dữ liệu (phạm vi ngày) trong một số giờ trong ngày không?

Chúc may mắn và vui lòng đăng thêm chi tiết về kịch bản của bạn nếu bạn muốn có các gợi ý chính xác hơn ...

Answer 6

Điều chỉnh truy vấn có lẽ là nơi tốt nhất để bắt đầu. Mặc dù tôi không biết bạn đang tạo báo cáo, bước đó không thực sự mất nhiều thời gian. Một truy vấn hoạt động kém, mặt khác hoàn toàn có thể giết hiệu suất của bạn.

Tùy thuộc vào những gì bạn thấy khi xem truy vấn, bạn có thể cần phải thêm một số chỉ mục hoặc thậm chí có thể thiết lập bảng để lưu trữ thông tin cho báo cáo theo cách không chuẩn hóa để làm cho báo cáo có sẵn nhanh hơn. Bảng denormalized này sau đó có thể được làm mới (thông qua một SQL Server Job) mỗi giờ, hoặc với bất kỳ tần số yêu cầu của bạn dictate (trong vòng lý do).

Nếu 'báo cáo tương đối tĩnh, không có thông số đầu vào người dùng khác nhau, thì việc lưu vào bộ nhớ cache báo cáo chạy sớm hơn trong ngày cũng là một ý tưởng hay, nhưng thật khó để nói thêm về điều này mà không biết tình huống của bạn.

Đối với một vấn đề như thế này bạn thực sự cần phải bắt đầu tại cơ sở dữ liệu trừ khi bạn có lý do để nghi ngờ báo cáo của bạn tạo ra mã là thủ phạm. Bạn có thể sử dụng nhiều băng tần khác nhau, nhưng nếu db của bạn là nguyên nhân gốc thì các giải pháp đó sẽ không mở rộng và bạn có thể gặp phải các vấn đề tương tự (hoặc tệ hơn) trong tương lai .