Що обмежує кількість одночасних підключень, які моя програма ASP.NET може зробити до веб-служби?

У мене є програма ASP.NET 4.0, яка працює поверх IIS 7.5 на 64-розрядному комп'ютері Windows Server 2008 R2 Enterprise з модулями оперативної пам'яті, процесором, диском тощо.

З кожним веб-запитом програма ASP.NET встановлює підключення до серверної веб-служби (через необроблені сокети), яка працює на тій самій машині.

Проблема. Здається, існує щось, що обмежує кількість одночасних підключень до серверної веб-служби. Підозріло, що кількість одночасних з'єднань досягає 16.

Я знайшов цю ключову статтю від Microsoft, яка пояснює, як налаштувати параметри IIS для розміщення програм ASP.NET, які роблять багато запитів веб-служб: http://support.microsoft.com/?id=821268#tocHeadRef

Я дотримувався рекомендацій статті, але все одно не везло. Особливо цікавим є maxconnectionпараметр, який я навіть зіткнувся з 999.

Будь-які ідеї, що ще може бути придушенням зв’язків?

Примітка: Коли я виключаю IIS із суміші і замовлюю клієнтів, які підключаються безпосередньо до серверної веб-служби, він із задоволенням відкриє стільки підключень, скільки мені потрібно, тому я впевнений, що серверна система не є вузьким місцем. Це має бути щось у IIS / ASP.NET-land.

Ось відповідний розділ, machine.configякий, я впевнений, читає програма (перевірено за допомогою 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>

Більшість наведених тут відповідей стосуються кількості вхідних запитів до вашої серверної веб-служби, а не кількості вихідних запитів, які ви можете зробити із вашої програми ASP.net до вашої серверної служби.

Тут не ваша внутрішня сервісна служба регулює швидкість вашого запиту, це кількість відкритих з'єднань, яку ваша програма, що телефонує, готова встановити до тієї самої кінцевої точки (тієї ж URL-адреси).

Ви можете зняти це обмеження, додавши наступний розділ конфігурації до файлу machine.config:

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

Звичайно, ви можете вибрати більш розумну цифру, якщо хочете, наприклад, 50 або 100 одночасних з'єднань. Але вищезазначене відкриє його аж до макс. Ви також можете вказати конкретну адресу для правила відкритого ліміту вище, а не "*", що вказує на всі адреси.

Документація MSDN для System.Net.connectionManagement

Ще один чудовий ресурс для розуміння ConnectManagement у .NET

Сподіваюся, це вирішить вашу проблему!

EDIT: На жаль, я бачу, що у вас є управління з’єднаннями, згадане у коді вище. Я залишу свою вищезазначену інформацію, оскільки вона актуальна для майбутніх запитувачів із такою ж проблемою. Однак, зверніть увагу, що в даний час на більшості сучасних серверів є 4 різні файли machine.config!

Існує .NET Framework v2, що працює як під 32-розрядною, так і під 64-розрядною версіями, а також .NET Framework v4 також працює під 32-розрядною та 64-розрядною версіями. Залежно від вибраних налаштувань для вашого пулу програм ви можете використовувати будь-який із цих 4 різних файлів machine.config! Будь ласка, перевірте всі 4 файли machine.config, які зазвичай знаходяться тут:

• 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

Я усвідомлюю, що питання може бути досить старим, але ви кажете, що бекенд працює на тому самому сервері. Це означає, що на іншому порту, можливо, крім порту за замовчуванням 80.

Я читав, що коли ви використовуєте елемент конфігурації "connectionManagement", вам потрібно вказати номер порту, якщо він відрізняється від типового 80.

ПОСИЛАННЯ: Налаштування maxConnection може не працювати навіть autoConfig = false в ASP.NET

По-друге, якщо ви вирішите використовувати конфігурацію за замовчуванням (address = "*"), розширену з вашим власним серверним значенням, ви можете розглянути можливість встановлення конкретного значення на перше місце! В іншому випадку, якщо зроблений запит, спочатку збігається * і береться за промовчанням 2 з'єднання. Так само, як коли ви використовуєте цей розділ у web.config.

ПОСИЛАННЯ: <видалити> Елемент для керування підключенням (Налаштування мережі)

Сподіваюся, це комусь допомагає.

Чи можливо, що ви використовуєте посилання на веб-службу на основі WCF? За замовчуванням ServiceThrottlingBehavior.MaxConcurrentCalls має значення 16.

Ви можете спробувати оновити <serviceThrottling>елемент поведінки посилання на службу

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

(Зверніть увагу, що я б рекомендував наведені вище налаштування.) Докладніше про налаштування відповідного елемента див. У MSDN<behavior> .

Ви намагалися програмно встановити значення статичної властивості DefaultConnectionLimit ?

Ось гарне джерело інформації про справжній головний біль ... Використання потоків ASP.NET у IIS 7.5, IIS 7.0 та IIS 6.0 , з оновленнями для framework 4.0.

Див. Розділ «Потоки» на цій сторінці: http://msdn.microsoft.com/en-us/library/ff647786.aspx , разом із розділом «З’єднання».

Ви пробували підвищити атрибут maxconnection вашого параметра processModel?

Якщо це не визначено у веб-службі, додатку чи сервері (apache або IIS), на якому розміщується витратний матеріал веб-служби, ви можете створювати нескінченні з'єднання до збою

Під час тестування продуктивності мірою, якою я керуюся, є RPS, тобто стільки запитів в секунду може сервер обслуговувати в межах прийнятної затримки.

теоретично один сервер може виконувати стільки запитів одночасно, скільки кількість ядер на ньому ..

Не схоже на те, що проблема полягає у моделі потоків ASP.net, оскільки вона потенційно може обслуговувати тисячі RPP. Здається, проблемою може бути ваша програма. Чи використовуєте ви якісь примітиви синхронізації?

також яка затримка на ваших веб-службах, чи вони дуже швидко реагують (протягом мікросекунд), якщо ні, тоді ви можете розглянути асинхронні дзвінки, тому ви не закінчите блокування

Якщо це щось не заважає, можливо, ви захочете профілізувати свій код за допомогою Visual Studio або Redgate Profiler