2009-02-22 43 views
10

Tôi đang tìm các phương pháp hay nhất để triển khai TraceListener sẽ ghi nhật ký bên trong máy chủ SQL từ một ứng dụng ASP.NET.Triển khai TraceListener tùy chỉnh trong .NET

Điều gì sẽ được tính đến khi triển khai lớp học như vậy để tránh giảm hiệu suất?

Quy trình được lưu trữ có nhanh hơn các câu lệnh INSO ADO.NET đơn giản không? Tôi thực sự thích ý tưởng viết nhật ký vào bộ đệm tạm thời trong bộ nhớ và chuyển nó vào cơ sở dữ liệu tại một số điểm sau đó từ một chuỗi nền, nhưng cấu trúc dữ liệu nào phù hợp nhất cho kịch bản như vậy? Queue<T> có vẻ giống như một ứng cử viên tốt nhưng tôi không thể thêm các yếu tố vào nó mà không có một số cơ chế đồng bộ hóa.

Tôi tìm thấy trên internet một article hiển thị ví dụ về một TraceListener tùy chỉnh ghi vào máy chủ SQL nhưng trước khi đưa nó vào mã sản xuất, tôi muốn có thêm một số phản hồi.

+0

Bạn cũng muốn biết điều này! – Cerebrus

+0

Tôi không thể truy cập bài viết được liên kết, tôi nghĩ rằng [bài viết này] (http://www.codeguru.com/csharp/.net/article.php/c19405/Tracing-in-NET-and-Implementing- Your-Own-Trace-Listeners.htm) là một trong những bạn đang đề cập đến. –

Trả lời

4

Thủ tục được lưu trữ sẽ không có bất kỳ SQL nào được tối ưu hóa nhanh hơn. Tôi thích một thủ tục lưu trữ trên SQL hardcoding trong ứng dụng của tôi, nhưng nếu bạn sẽ tạo ra các báo cáo chèn thì đó là tốt hơn.

Sử dụng bộ đệm là một ý tưởng hay nếu bạn đồng ý với ý tưởng rằng bạn có thể mất dữ liệu. Nếu bạn muốn tách riêng máy khách khỏi chèn và bạn muốn nó bền thì bạn có thể sử dụng MSMQ. Sau đó, bạn có thể viết một dịch vụ cửa sổ có thể xử lý hàng đợi và nó woulod được hoàn toàn tách ra từ ứng dụng. Nó cũng có thể tổng hợp các bản ghi từ nhiều máy chủ nếu bạn có một trang trại máy chủ.

+0

@Josh, MSMQ có vẻ là một ý tưởng hay. Tôi không có kinh nghiệm với nó nhưng tôi sẽ đào sâu hơn nữa. Cảm ơn con trỏ. –

4

log4net sẽ đổ dấu vết để một db sql với một đống toàn bộ tùy chọn tuôn ra, vv kiểm tra xem nó: http://logging.apache.org/log4net/release/features.html

log4net được chứng minh. nếu bạn có thể tránh 'viết lại bánh xe' thì nó có tốt không?

+0

@cottsak, tôi hoàn toàn đồng ý với bạn.log4net là một khung đăng nhập tuyệt vời, nhưng chính sách của công ty không cho phép tôi sử dụng nó. Đó là lý do tại sao tôi phải phát minh lại bánh xe :-) –

+4

Thay đổi chính sách của công ty đó. Họ đang lãng phí thời gian của bạn và tiền của họ khi bạn viết lại nó. –

1

tôi không thể nói là liệu SP có nhanh hơn chèn ADO hay không nhưng tôi sẽ luôn đề xuất giữ truy vấn/truy vấn không trong ứng dụng của bạn, KHÔNG phải trong kho dữ liệu. như bạn bây giờ, kho dữ liệu dành cho dữ liệu chứ không phải logic. tránh SP.

MS SQL Server là một phần phức tạp của máy móc và tôi không nghĩ rằng ứng dụng của bạn sẽ có thể gây ra chặn trong mã của bạn từ quá nhiều đăng nhập vào db của bạn. rõ ràng điều này là tùy thuộc vào việc thực hiện cụ thể của bạn và từ quan tâm của bạn trong hiệu suất tôi có thể giả định bạn có ý định hỗ trợ khối lượng cao. những gì im nói là tôi không nghĩ rằng bạn cần một hàng đợi trong bộ nhớ hoặc dịch vụ để bọc quá trình đăng nhập. chỉ cần tuôn ra dấu vết để db trong ứng dụng aspnet của bạn và quên đi bộ nhớ đệm/đỏ bừng. SQL sẽ xem xét sau khi giữ các truy vấn đăng nhập trong bộ nhớ và nó sẽ xem xét sau khi ghi nó vào đĩa - trong thực tế nó quản lý điều này rất tốt. Bộ đệm truy vấn của SQL sẽ đảm bảo mã của bạn không chặn khi u xóa dấu vết của bạn. nếu bạn không tin tôi, hãy thử nó với dấu thời gian trong cửa sổ gỡ lỗi của bạn hoặc một cái gì đó. nếu bạn cần phải tinh chỉnh nó, việc tinh chỉnh sẽ nằm trong cài đặt bộ nhớ của db của bạn. u không cần phải phát minh ra một wrapper ở đây, sử dụng SP hoặc bắt đầu một dịch vụ khác trên máy chủ của bạn (như MSMQ), điều này sẽ chỉ ăn nhiều hơn của CPU quý giá của bạn và mem.

Các vấn đề liên quan