2012-05-18 23 views
12

Tôi đã phát triển một máy chủ C# trên cả Visual Studio 2010 và Mono Develop 2.8. NET Framework 4.0Vấn đề khả năng mở rộng máy chủ C# trên linux

Dường như máy chủ này hoạt động tốt hơn nhiều (về khả năng mở rộng) trên Windows so với trên Linux. Tôi đã thử nghiệm khả năng mở rộng máy chủ trên Windows nguyên bản (12 lõi vật lý), và 8 và 12 lõi Windows và Ubuntu Virtual Machines bằng cách sử dụng công cụ ab của Apache.

Thời gian phản hồi của cửa sổ khá phẳng. Nó bắt đầu chọn khi mức đồng thời tiếp cận/vượt qua số lượng lõi.

Vì lý do nào đó, thời gian phản hồi của Linux kém hơn nhiều. Họ phát triển khá nhiều tuyến tính bắt đầu từ cấp 5 đồng thời. Ngoài ra 8 và 12 lõi Linux VM hành xử tương tự.

Vì vậy, câu hỏi của tôi là: tại sao nó hoạt động kém hơn trên Linux? (và Làm cách nào tôi có thể khắc phục điều đó?).

Hãy xem biểu đồ đính kèm, nó hiển thị thời gian trung bình để đáp ứng 75% yêu cầu làm hàm đồng thời yêu cầu (thanh phạm vi được đặt ở 50% và 100%). time to fulfill 75% of the request as a function of the request concurrency

Tôi có cảm giác rằng điều này có thể do Bộ sưu tập rác của mono. Tôi đã thử chơi xung quanh với các thiết lập GC nhưng tôi đã không thành công. Bất kỳ đề xuất nào?

Một số thông tin cơ bản bổ sung: máy chủ dựa trên trình nghe HTTP nhanh chóng phân tích cú pháp các yêu cầu và xếp hàng chúng trên một nhóm luồng. Hồ bơi thread sẽ trả lời những yêu cầu đó với một số toán học chuyên sâu (tính toán câu trả lời trong ~ 10 giây).

+1

"Máy chủ C#" là gì? Điều đó khác với máy chủ? Ý tôi là, trong tiêu đề của bạn, "C#" có được sử dụng như một tính từ? Là một "C# máy chủ" một loại máy chủ? –

+0

> một số toán chuyên sâu (tính toán câu trả lời trong ~ 10 giây). Tôi nghĩ rằng vấn đề của bạn là có .. Nó không phải là kịch bản điển hình cho một máy chủ. Có bao nhiêu lõi mà phần cứng vật lý của bạn có, 12? Biểu đồ trông như thế nào sau 10 yêu cầu đồng thời? – Soonts

+0

Như tôi biết, mono không phù hợp cho những mục đích sử dụng này. Sự phát triển của mono được tập trung vào các ứng dụng máy tính để bàn nhỏ. Tôi nhận được thông tin này từ một nhà phát triển mono, tôi sẽ cố gắng tìm thêm thông tin và sẽ đăng ở đây nếu tôi tìm thấy. – LawfulHacker

Trả lời

4

Bạn cần cách ly vị trí của vấn đề trước tiên. Bắt đầu bằng cách theo dõi việc sử dụng bộ nhớ của bạn với HeapShot. Nếu nó không phải là bộ nhớ, sau đó cấu hình mã của bạn để xác định các phương pháp tiêu tốn thời gian.

Trang này, Performance Tips: Writing better performing .NET and Mono applications, chứa một số thông tin hữu ích bao gồm sử dụng trình đơn sơ yếu.

Thao tác chuỗi quá mức và Quyền anh thường là thủ phạm mã 'ẩn' không quy mô tốt.

+0

Cảm ơn Mitch. Tôi sẽ thanh toán các công cụ/tài liệu bạn đã đề xuất. Nhưng tôi có thể nói với bạn rằng máy chủ đã được (chuyên sâu) được lược tả và tối ưu hóa trên các cửa sổ (sử dụng eqatec profiler). Hành vi của máy chủ trên Windows là rất tốt: phản hồi bằng phẳng (được thử nghiệm với tối đa 12 yêu cầu đồng thời trên một máy lõi vật lý 12). Thay vào đó nó thực hiện tồi tệ hơn nhiều trên linux.Một tắc nghẽn băng thông bộ nhớ nên ảnh hưởng đến linux và windows máy theo cùng một cách, đây là lý do tại sao tôi loại trừ nó ra. Hãy nhìn vào biểu đồ tôi đã uploa. Tôi không thể đính kèm nó trước vì chính sách chống thư rác stackoverflow (tôi là người dùng mới) – Enio

+0

Tôi đã sử dụng công cụ bạn đã đề xuất (HeapShot) để lược tả hành vi GC. Có vẻ như có ~ 10 bộ sưu tập rác cho mỗi 20 yêu cầu mà tôi gửi tới máy chủ. Mỗi một trong các sự kiện GC này xử lý ít hơn 10Mb RAM. Hầu hết các công việc được thực hiện giải phóng System.Single []. dù sao nó có vẻ với tôi rằng những sự kiện bộ nhớ là quá hiếm để tác động đến khả năng mở rộng máy chủ. Bạn nghĩ sao? – Enio

1

Hãy thử bộ thu gom rác sgen (và cho điều đó, nên sử dụng Mono 2.11.x). Nhìn vào trang đơn nam để biết thêm chi tiết.

+0

Cảm ơn. Tôi đã thử chạy với mono --gc = sgen. Rất tiếc, hành vi vẫn giống với – Enio

+0

phiên bản mono nào? – knocte

+0

một tùy chọn khác mà bạn có thể thử là chương trình phụ trợ LLVM – knocte

1

Tôi không tin đó là do GC. AFAIK tác dụng phụ GC nên được phân phối đồng đều nhiều hơn hoặc ít hơn trên các chủ đề.

phỏng đoán mù của tôi là: bạn có thể sửa lỗi bằng cách chơi với ThreadPool.SetMinThreads/SetMaxThreads API.

+0

Tôi đã thử thay đổi số lượng các chủ đề tối thiểu/tối đa/io và dường như không có hiệu ứng (dương) trên khả năng mở rộng. Nhưng dù gì cũng cảm ơn. Btw hiệu ứng được phân bố đều trên tất cả các chủ đề: vui lòng xem các thanh lỗi trên các đường cong màu nâu và màu da cam (các đường đơn trên) tại đồng thời 9-10. bạn có thể thấy thời gian trả lời giống nhau như thế nào đối với tất cả các yêu cầu. – Enio

+0

OK, dự đoán của tôi mù # 2: các cổng hoàn thành I/O (được sử dụng bởi hồ bơi thread NET CLR) được phát minh vào năm 1993 (Windows NT 3.5) và kể từ thời điểm đó được tinh chỉnh và sửa lỗi. OTOH, epoll (bản sao IOCP, được MONO sử dụng cho cùng một mục đích) chỉ có ở đây từ năm 2002, vì vậy Windows IOCP chỉ là tốt hơn. Trên Linux, mọi thứ đều tốt cho đến khi yêu cầu đồng thời * 2 Soonts

+0

BTW, khi đo điểm chuẩn, bạn có bắt đầu đồng thời tất cả yêu cầu không? Điều gì thay đổi nếu bạn sẽ khởi động chúng trong khoảng thời gian 1-2 giây sau cái khác? – Soonts

0

Nếu bạn mã ném rất nhiều trường hợp ngoại lệ, sau đó mono là 10x nhanh hơn so với .NET

+2

thật tuyệt vời! Nhưng vấn đề của tôi là ngược lại: khả năng mở rộng máy chủ là tốt hơn nhiều trên các cửa sổ hơn trên mono/linux. – Enio

1

Tôi rất muốn giới thiệu bạn làm một số cấu hình trên các mã liên quan đến cách phương pháp cá nhân dài đang chạy. Rất có thể bạn đang thấy một số khó khăn về khóa đa luồng hoặc tương tự mà không được xử lý hoàn hảo bằng mono. Việc sử dụng CPU và RAM cũng sẽ hữu ích.

1

Tôi tin rằng đây có thể là vấn đề tương tự mà chúng tôi đã theo dõi liên quan đến hồ bơi luồng và hành vi bắt đầu cho các chuỗi mới cũng như lỗi trong việc triển khai mono của setMinThreads.Vui lòng xem câu trả lời của tôi về chuỗi đó để biết thêm thông tin: https://stackoverflow.com/a/12371795/1663096

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