Điều gì đang giới hạn số lượng kết nối đồng thời mà ứng dụng ASP.NET của tôi có thể thực hiện với một dịch vụ web?


90

Tôi có một ứng dụng ASP.NET 4.0 đang chạy trên đỉnh IIS 7.5 trên máy Windows Server 2008 R2 Enterprise 64-bit với bộ nhớ RAM, CPU, đĩa, v.v.

Với mọi yêu cầu web, ứng dụng ASP.NET tạo kết nối với dịch vụ web phụ trợ (thông qua các ổ cắm thô) đang chạy trên cùng một máy.

Vấn đề: Dường như có điều gì đó giới hạn số lượng kết nối đồng thời với dịch vụ web phụ trợ. Thật đáng ngờ, số lượng kết nối đồng thời đang đứng đầu là 16.

Tôi đã tìm thấy bài viết quan trọng này của Microsoft giải thích cách tinh chỉnh cài đặt IIS 'để chứa các ứng dụng ASP.NET tạo ra nhiều yêu cầu dịch vụ web: http://support.microsoft.com/?id=821268#tocHeadRef

Tôi đã làm theo lời giới thiệu của bài báo, nhưng vẫn không may mắn. Cài đặt đặc biệt thú vị là maxconnectioncài đặt, mà tôi thậm chí đã chạm đến 999.

Bất kỳ ý tưởng nào khác có thể được điều chỉnh kết nối?

Lưu ý: Khi tôi cắt IIS ra khỏi hỗn hợp và để các máy khách kết nối trực tiếp với dịch vụ web phụ trợ, nó sẽ vui vẻ mở ra nhiều kết nối mà tôi cần, vì vậy tôi khẳng định rằng phần phụ trợ không phải là nút cổ chai. Nó phải là một cái gì đó trong IIS / ASP.NET-land.

Đây là phần có liên quan machine.configmà tôi chắc chắn đang được ứng dụng đọc (được xác minh bằng appcmd.exe):

<system.web>
    <processModel autoConfig="false" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" />
    <httpRuntime minFreeThreads="176" minLocalRequestFreeThreads="152"/>

    <httpHandlers />

    <membership>
        <providers>
            <add name="AspNetSqlMembershipProvider"
                type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
                connectionStringName="LocalSqlServer"
                enablePasswordRetrieval="false"
                enablePasswordReset="true"
                requiresQuestionAndAnswer="true"
                applicationName="/"
                requiresUniqueEmail="false"
                passwordFormat="Hashed"
                maxInvalidPasswordAttempts="5"
                minRequiredPasswordLength="7"
                minRequiredNonalphanumericCharacters="1"
                passwordAttemptWindow="10"
                passwordStrengthRegularExpression="" />
        </providers>
    </membership>

    <profile>
        <providers>
            <add name="AspNetSqlProfileProvider" connectionStringName="LocalSqlServer" applicationName="/"
                type="System.Web.Profile.SqlProfileProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
        </providers>
    </profile>

    <roleManager>
        <providers>
            <add name="AspNetSqlRoleProvider" connectionStringName="LocalSqlServer" applicationName="/"
                type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
            <add name="AspNetWindowsTokenRoleProvider" applicationName="/"
                type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
        </providers>
    </roleManager>
</system.web>
<system.net>
    <connectionManagement>
        <add address="*" maxconnection="999"/>
    </connectionManagement>
</system.net>

@DanB có một điểm tốt ở đây - bạn đo lường số lượng kết nối đồng thời như thế nào?
Jeremy McGee

@JeremyMcGee Tôi đang đo số lượng kết nối đồng thời bằng cách chạy TCPView trên máy chủ để xem có bao nhiêu kết nối phụ trợ được thực hiện bởi các quy trình công nhân IIS.
Rob Sobers

Các máy khách Web đang chạy trên các máy độc lập hay cùng một máy? (Kiểm tra rằng không có throttling client-side xảy ra.)
Jeremy McGee

3
@JeremyMcGee Máy riêng biệt. 1 kết nối máy khách-máy chủ trên mỗi máy. Ngoài ra, chúng tôi biết rằng không có bất kỳ điều chỉnh nào ở đâu đó trên mạng bởi vì khi chúng tôi nhấn trực tiếp vào phần phụ trợ (cũng xảy ra qua HTTP), chúng tôi không gặp phải nút cổ chai.
Rob Sobers

1
Rob, bạn đã bao giờ tìm ra giải pháp dứt điểm cho việc này chưa?
ElectronicKT

Câu trả lời:


104

Hầu hết các câu trả lời được cung cấp ở đây đề cập đến số lượng yêu cầu gửi đến dịch vụ web phụ trợ của bạn, không phải số lượng yêu cầu gửi đi mà bạn có thể thực hiện từ ứng dụng ASP.net đến dịch vụ phụ trợ của mình.

Nó không phải là dịch vụ web phụ trợ của bạn đang điều chỉnh tỷ lệ yêu cầu của bạn ở đây, đó là số lượng kết nối mở mà ứng dụng gọi điện của bạn sẵn sàng thiết lập đến cùng một điểm cuối (cùng một URL).

Bạn có thể loại bỏ hạn chế này bằng cách thêm phần cấu hình sau vào tệp machine.config của mình:

<configuration>
  <system.net>
    <connectionManagement>
      <add address="*" maxconnection="65535"/>
    </connectionManagement>
  </system.net>
</configuration>

Tất nhiên, bạn có thể chọn một số hợp lý hơn nếu bạn muốn, chẳng hạn như 50 hoặc 100 kết nối đồng thời. Nhưng ở trên sẽ mở nó lên tối đa. Bạn cũng có thể chỉ định một địa chỉ cụ thể cho quy tắc giới hạn mở ở trên thay vì dấu '*' cho biết tất cả các địa chỉ.

Tài liệu MSDN cho System.Net.connectionManagement

Một tài nguyên tuyệt vời khác để hiểu ConnectManagement trong .NET

Hy vọng điều này sẽ giải quyết vấn đề của bạn!

CHỈNH SỬA: Rất tiếc, tôi thấy bạn có quản lý kết nối được đề cập trong mã của bạn ở trên. Tôi sẽ để lại thông tin ở trên của tôi vì nó có liên quan cho những người hỏi trong tương lai có cùng vấn đề. Tuy nhiên, xin lưu ý rằng hiện tại có 4 tệp machine.config khác nhau trên hầu hết các máy chủ cập nhật!

Có .NET Framework v2 chạy dưới cả 32 bit và 64 bit cũng như .NET Framework v4 cũng chạy dưới cả 32 bit và 64 bit. Tùy thuộc vào cài đặt đã chọn cho nhóm ứng dụng của bạn, bạn có thể sử dụng bất kỳ một trong 4 tệp machine.config khác nhau này! Vui lòng kiểm tra tất cả 4 tệp machine.config thường nằm ở đây:

  • C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
  • C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG
  • C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Config
  • C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Config

Yup, tôi đã bảo vệ căn cứ đó. Dù sao cũng cảm ơn @BenSwayne! Tôi đã xác minh rằng tôi đã sửa đổi chính xác machine.config(64-bit 4.0).
Rob Sobers

@RobSobers: Trong trường hợp này, tôi sẽ hơi nghi ngờ về mã triển khai. Có lẽ bạn đang chạy ra khỏi chủ đề hoặc cái gì đó? Bạn có thể ném mã gọi dịch vụ web TcpClient của mình vào một ứng dụng bảng điều khiển và xem liệu bạn có thể đạt được tỷ lệ yêu cầu tốt hơn không? Điều này sẽ chứng minh rằng đó là cấu hình IIS cụ thể hay cấu hình .NET rộng hơn hoặc mã của bạn.
BenSwayne

Dòng này có đi trong máy khách không?
Uri Abramson

cảm ơn bạn, cài đặt của bạn kết hợp với twekaing processModel từ codeproject.com/Articles/133738/… đã sửa "ISAPI 'C: \ windows \ Microsoft.Net \ Framework \ v2.0.050727 \ aspnet_isapi.dll' được báo cáo là không lành mạnh vì lý do sau : Sự cố 'Đã phát hiện thấy
chốt chặn

@BenSwayne có áp dụng khái niệm tương tự cho kết nối SMTP không? Tôi đang thiết kế một ứng dụng gửi email hàng loạt, vậy thuộc tính ConnectionManagement này cũng sẽ hữu ích trong việc gửi hàng loạt thư (sử dụng đa luồng cho chức năng mail.send )?
vibs2006 27/12/16

7

Tôi nhận ra câu hỏi có thể khá cũ, nhưng bạn nói rằng phần phụ trợ đang chạy trên cùng một máy chủ. Điều đó có nghĩa là trên một cổng khác, có thể khác với cổng mặc định 80.

Tôi đã đọc rằng khi bạn sử dụng phần tử cấu hình "connectionManagement", bạn cần chỉ định số cổng nếu nó khác với số 80 mặc định.

LINK: cài đặt maxConnection có thể không hoạt động ngay cả autoConfig = false trong ASP.NET

Thứ hai, nếu bạn chọn sử dụng cấu hình mặc định (địa chỉ = "*") được mở rộng với giá trị phụ trợ cụ thể của riêng bạn, bạn có thể cân nhắc đặt giá trị cụ thể trước! Ngược lại, nếu một yêu cầu được thực hiện, dấu * khớp trước và lấy giá trị mặc định của 2 kết nối. Giống như khi bạn sử dụng phần này trong web.config.

LINK: <remove> Phần tử cho kết nối Quản lý (Cài đặt mạng)

Hy vọng nó sẽ giúp một ai đó.


5

Có thể bạn đang sử dụng tham chiếu dịch vụ web dựa trên WCF? Theo mặc định, ServiceThrottlingBehavior.MaxConcurrentCalls là 16.

Bạn có thể thử cập nhật <serviceThrottling>phần tử của hành vi tham chiếu dịch vụ của mình

<serviceThrottling
    maxConcurrentCalls="999" 
    maxConcurrentSessions="999" 
    maxConcurrentInstances="999" />

(Lưu ý rằng tôi khuyên bạn nên cài đặt ở trên.) Xem MSDN để biết thêm thông tin về cách định cấu hình <behavior>phần tử thích hợp .


Tôi ước chúng ta đã có, nhưng chúng ta không. Dịch vụ đang được sử dụng đang chạy trong Apache / Python / mod_wsgi trên một máy khác và như Rob đã đề cập, rõ ràng đây không phải là vấn đề.
Benjamin Pollack 24/10/11

Tham chiếu dịch vụ nằm trên máy khách. Khách hàng của bạn đang sử dụng dịch vụ Apache như thế nào?
John Saunders

Giống như John đã nói: việc điều chỉnh được đặt trên khách hàng sử dụng dịch vụ web. Có lẽ cụm từ "hành vi dịch vụ của bạn" hơi gây hiểu lầm. Nó có ý nghĩa hơn khi được viết là "hành vi tham chiếu dịch vụ của bạn" không?
Ruben

@john Nó được sử dụng thông qua a TcpClient(dịch vụ cung cấp các đốm màu nhị phân tùy chỉnh, không phải WCF / SOAP hoặc tương tự). Các tùy chọn cấu hình đó dường như hoàn toàn tác động đến bạn nếu bạn sử dụng ServiceHostchứ không phải TcpClient; tui bỏ lỡ điều gì vậy?
Benjamin Pollack

Tại sao không sử dụng "Thêm Tham chiếu Dịch vụ"?
John Saunders

3

Bạn đã cố gắng đặt giá trị của thuộc tính DefaultConnectionLimit tĩnh theo lập trình chưa?

Đây là một nguồn thông tin tốt về vấn đề đau đầu thực sự đó ... ASP.NET Thread Sử dụng trên IIS 7.5, IIS 7.0 và IIS 6.0 , với các bản cập nhật cho framework 4.0.


Tôi nghĩ rằng điều này sẽ không thành vấn đề, nhưng dù sao thì tôi cũng sẽ thử.
Rob Sobers

Đây là cách chúng tôi đã sửa nó một vài năm trước. Chúng tôi đã có các vấn đề về đồng thời và điều này dường như đã làm sáng tỏ nó. Net.ServicePointManager.DefaultConnectionLimit = 1000 là những gì chúng tôi đã sử dụng. Bạn phải đặt nó TRƯỚC KHI tạo các lớp kết nối.
Brain2000

2

Xem phần "Phân luồng" của trang này: http://msdn.microsoft.com/en-us/library/ff647786.aspx , cùng với phần "Kết nối".

Bạn đã thử nâng thuộc tính maxconnection của cài đặt processModel chưa?


Vâng tôi có. Nhưng bài viết mà bạn đã trích dẫn chỉ ra một điều thú vị mà các bài viết khác về chủ đề này đã bỏ qua: maxconnectionthuộc tính này không áp dụng cho các cuộc gọi dịch vụ web cục bộ . Trong trường hợp cụ thể này, dịch vụ web cục bộ, nhưng chúng tôi gặp phải vấn đề tương tự trong một môi trường khác mà dịch vụ không cục bộ.
Rob Sobers

@RobSobers - Tôi nghĩ rằng liên kết ở trên đáng được xem lại lần thứ hai. Kiểm tra phần giới thiệu minLocalRequestFreeThreads- Quy trình công nhân này sử dụng cài đặt này để xếp hàng các yêu cầu từ localhost (nơi ứng dụng Web gọi một dịch vụ Web trên cùng một máy chủ ) nếu số luồng có sẵn trong nhóm luồng thấp hơn số này. Cài đặt này tương tự như minFreeThreads, nhưng nó chỉ áp dụng cho các yêu cầu sử dụng localhost .
Ahmad

@Ahmad Yup, tôi đặt minLocalRequestFreeThreadscũng (xem tôi machine.configtrong câu hỏi.
Rob Sobers

0

Nếu nó không được xác định trong dịch vụ web hoặc ứng dụng hoặc máy chủ (apache hoặc IIS) đang lưu trữ dịch vụ web tiêu dùng thì bạn có thể tạo kết nối vô hạn cho đến khi không thành công


0

trong khi thực hiện kiểm tra hiệu suất, thước đo tôi thực hiện là RPS, đó là số lượng yêu cầu mỗi giây mà máy chủ có thể phân phối trong độ trễ chấp nhận được.

về mặt lý thuyết, một máy chủ chỉ có thể chạy đồng thời nhiều yêu cầu bằng số lõi trên nó ..

Có vẻ như vấn đề không phải là mô hình phân luồng của ASP.net, vì nó có khả năng phục vụ hàng nghìn rps. Có vẻ như vấn đề có thể là ứng dụng của bạn. Bạn có đang sử dụng bất kỳ nguyên thủy đồng bộ hóa nào không?

cũng như độ trễ trên các dịch vụ web của bạn là bao nhiêu, chúng có phản hồi rất nhanh không (trong vòng micro giây), nếu không thì bạn có thể muốn xem xét các cuộc gọi không đồng bộ, vì vậy bạn không bị chặn

Nếu điều này không bạn tạo ra điều gì đó, thì bạn có thể muốn lập hồ sơ cho mã của mình bằng visual studio hoặc redgate profile

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.