2011-10-19 27 views
8

Tôi có ứng dụng khách/máy chủ. Các thành phần máy chủ chạy, sử dụng WCF trong một thời trang 'remoting' (định dạng nhị phân, đối tượng phiên).Mã C# rất chậm với trình gỡ lỗi đính kèm; Lỗi của MemoryMappedFile?

Nếu tôi khởi động thành phần máy chủ và khởi chạy máy khách, tác vụ đầu tiên máy chủ hoàn thành trong < 0.5 giây.

Nếu tôi khởi động thành phần máy chủ có trình gỡ rối VS được đính kèm và sau đó khởi chạy ứng dụng khách, tác vụ sẽ mất 20 giây để hoàn thành.

Không có thay đổi mã - không có thay đổi biên dịch có điều kiện. Điều tương tự cũng xảy ra cho dù tôi có thành phần máy chủ được biên dịch và chạy trong 32-bit, 64 bit, với quy trình lưu trữ VS, không có quy trình lưu trữ VS hay bất kỳ sự kết hợp nào của những thứ đó.

Có lẽ quan trọng: Nếu tôi sử dụng VS.NET profiler (chế độ lấy mẫu), sau đó ứng dụng chạy nhanh như nếu không có chương trình gỡ rối kèm theo. Vì vậy, tôi không thể chẩn đoán nó theo cách đó. Chỉ cần kiểm tra, chế độ thiết bị cũng chạy nhanh. Tương tự cho chế độ lược tả đồng thời, hoạt động nhanh chóng.

dữ liệu chính:

  • Ứng dụng sử dụng đa luồng khá nặng (40 chủ đề trong hồ bơi thread tiêu chuẩn). Tạo chủ đề diễn ra nhanh chóng bất kể và không phải là điểm chậm. Có nhiều khóa, WaitHandle s và Monitor mẫu
  • Ứng dụng này hoàn toàn không có ngoại lệ.
  • Ứng dụng không tạo đầu ra giao diện điều khiển.
  • Ứng dụng là mã được quản lý hoàn toàn.
  • Ứng dụng không ánh xạ một vài tập tin trên đĩa để một MemoryMappedFile: 1x750MB và 12x8MB và một vài cái nhỏ hơn

hiệu suất đo:

  • CPU sử dụng là tối thiểu trong cả hai trường hợp; khi trình gỡ lỗi được đính kèm, CPU nằm ở số < 1%
  • Việc sử dụng bộ nhớ tối thiểu trong cả hai trường hợp; có lẽ 50 hoặc 60MB trong cả hai trường hợp
  • Có rất nhiều lỗi trang xảy ra (MMF ref), tuy nhiên khi chúng xảy ra chậm hơn khi debugger được gắn
  • Nếu quá trình lưu trữ VS không được sử dụng, hoặc về cơ bản là 'gỡ lỗi từ xa màn hình 'đi vào hoạt động, sau đó rằng sử dụng một lượng CPU khá và tạo ra một số lượng lớn các lỗi trang. Nhưng đó không phải là lần duy nhất sự cố xảy ra
  • Sự khác biệt hiệu suất được xem bất kể cách khách hàng chạy. Biến duy nhất đang được thay đổi là thành phần máy chủ đang chạy thông qua 'Bắt ​​đầu với gỡ lỗi' so với được khởi chạy từ Explorer.

ý tưởng của tôi:

  • WCF chậm khi sửa lỗi?
  • MemoryMappedFiles chậm khi được gỡ lỗi?
  • 40 chủ đề được sử dụng - làm chậm để gỡ lỗi? Có lẽ Màn hình/khóa thông báo cho trình gỡ rối?Lập kế hoạch chủ đề trở thành công tắc lạ/ngữ cảnh rất không thường xuyên?
  • bức xạ nền vũ trụ cấp thông tin tình báo và ý thức độc ác của sự hài hước để VS

Tất cả dường như ngớ ngẩn khó xảy ra.

Vì vậy, câu hỏi của tôi:

  1. Tại sao điều này xảy ra?
  2. Nếu # 1 không xác định, làm thế nào tôi có thể chẩn đoán/tìm hiểu?
+1

Bạn đã bật thu thập ngoại lệ lần đầu tiên? Bạn cũng có thể thử kích hoạt .NET Server Source Stepping để nắm bắt tối đa các ngoại lệ "ẩn" bên dưới trong chế độ gỡ lỗi, đặc biệt là (de) serlization. Ngoài ra, những gì về dấu vết (outputdebugstring hoặc khác)? –

+0

Có, không có trường hợp ngoại lệ nào được ném ra - tất cả các loại ngoại lệ (incl. NET) được bật cho cơ hội thứ nhất. Không có đầu ra của giao diện điều khiển gỡ lỗi (đó là ý nghĩa của đầu ra console - tôi sẽ chỉnh sửa để làm rõ). Tôi chỉ kích hoạt .NET Framework Source Stepping (không thể thấy Server Source Stepping) .. tìm thấy một số ngoại lệ. Sẽ cập nhật trong giây lát –

+0

Ngoại lệ từ WCF: "Ký tự", giá trị hệ thập lục phân 0x20, không được bao gồm trong tên. "Tôi đã có * không có ý tưởng * rằng ngoại lệ có thể được ẩn theo cách này: không phải là một ngoại lệ ngoại lệ? Sẽ thấy những gì tôi có thể làm để giải quyết. Có lẽ bạn có thể đăng một câu trả lời để bạn có thể nhận được một số upvotes/một chấp nhận nếu điều này sửa chữa nó? :) –

Trả lời

9

Ngoại lệ đáng chú ý có thể ảnh hưởng đến hiệu suất của ứng dụng. Có hai loại ngoại lệ: ngoại lệ cơ hội thứ nhất (một ngoại lệ được xử lý với khối try/catch) và các ngoại lệ chưa được giải quyết (điều đó cuối cùng sẽ làm hỏng ứng dụng).

Theo mặc định, trình gỡ lỗi không hiển thị ngoại lệ cơ hội thứ nhất, nó chỉ hiển thị các ngoại lệ chưa được xử lý. Và theo mặc định, nó cũng chỉ hiển thị ngoại lệ xảy ra trong mã của bạn. Tuy nhiên, ngay cả khi nó không hiển thị chúng, nó vẫn xử lý chúng, do đó hiệu suất của nó có thể bị ảnh hưởng (đặc biệt là trong các bài kiểm tra tải, hoặc chạy vòng lặp lớn).

Để bật ngoại lệ cơ hội thứ nhất hiển thị trong Visual Studio, hãy nhấp vào "Gỡ lỗi | Ngoại lệ" để gọi hộp thoại Ngoại lệ và kiểm tra "Thrown" trên phần "Thời gian chạy ngôn ngữ chung" (bạn có thể cụ thể hơn và chọn 1 ngoại lệ cơ hội bạn muốn xem).

Để bật hiển thị ngoại lệ cơ hội đầu tiên từ bất kỳ đâu trong ứng dụng, không chỉ từ mã của bạn, hãy nhấp vào "Tools | Options | Debugging | General" và tắt tùy chọn "Enable Just My Code".

Và đối với các trường hợp "chế độ pháp y cụ thể" này, tôi cũng khuyên bạn nên bật tính năng .NET Framework Source Stepping (yêu cầu bật "Chỉ kích hoạt mã của tôi"). Nó rất hữu ích để hiểu những gì đang xảy ra, đôi khi chỉ cần nhìn vào các cuộc gọi stack là rất cảm hứng - và hữu ích đặc biệt là trong trường hợp của mixup bức xạ vũ trụ :-)

Hai điều thú vị liên quan:

+1

Theo nhận xét khác của tôi, ngoại lệ đã hoàn toàn 'ẩn', cho đến khi tôi bật '.NET Framework Source Stepping'. Đã xảy ra lỗi khi 'SerializationInfo.SetValue()' đưa ra ngoại lệ về tham số 'string' không phải là tên phần tử XML hợp lệ, mặc dù nó sẽ tiếp tục hoạt động, và hơn nữa, tôi đã sử dụng NetTcpBinding (tức là trình định dạng nhị phân) . –

2

vì đây là một trong những kết quả đầu tiên khi googling cho vấn đề này, tôi muốn thêm giải pháp vấn đề của tôi ở đây với hy vọng tiết kiệm một ai đó 2 giờ nghiên cứu như tôi n trường hợp của tôi.

Mã của tôi bị chậm lại từ 30 giây mà không cần trình gỡ lỗi gắn liền với 4 phút bằng trình gỡ lỗi. bởi vì tôi quên xóa một điểm ngắt có điều kiện. Những điều này dường như làm chậm quá trình thực hiện rất nhiều, vì vậy hãy chú ý đến những người

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