ASP.NET uygulamamın bir web hizmetine yapabileceği eşzamanlı bağlantı sayısını sınırlayan nedir?

90

64-bit Windows Server 2008 R2 Enterprise makinesinde IIS 7.5'in üzerinde RAM, CPU, disk vb. İle çalışan bir ASP.NET 4.0 uygulamam var.

Her web isteğinde, ASP.NET uygulaması aynı makinede çalışan bir arka uç web hizmetine (ham soketler aracılığıyla) bağlantı kurar.

Sorun: Arka uç web hizmetine eşzamanlı bağlantı sayısını sınırlayan bir şey var gibi görünüyor. Şüpheli bir şekilde, eşzamanlı bağlantıların sayısı 16'ya yükseliyor.

Microsoft'tan çok sayıda web hizmeti isteği yapan ASP.NET uygulamalarını barındırmak için IIS ayarlarının nasıl değiştirileceğini açıklayan bu önemli makaleyi buldum: http://support.microsoft.com/?id=821268#tocHeadRef

Makalenin önerilerini takip ettim ama yine de şansım yok. Özellikle ilginç olan maxconnectionayar, 999'a bile çıkardığım ayardır.

Bağlantıları kısıtlayan başka ne olabileceğine dair bir fikriniz var mı?

Not: IIS'yi karışımdan çıkardığımda ve istemcilerin doğrudan arka uç web hizmetine bağlanmasını sağladığımda, ihtiyacım olduğu kadar mutlu bir şekilde çok sayıda bağlantı açacak, bu nedenle arka ucun darboğaz olmadığından eminim. IIS / ASP.NET alanında bir şey olmalı.

İşte machine.configuygulama tarafından okunduğundan emin olduğum ilgili bölüm (ile doğrulandı 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  web-services  iis 
— Rob Sobers
kaynak
@DanB burada iyi bir noktaya sahip - eşzamanlı bağlantıların sayısını nasıl ölçüyorsunuz?
— Jeremy McGee
@JeremyMcGee IIS çalışan işlemleri tarafından kaç arka uç bağlantısı yapıldığını görmek için sunucuda TCPView çalıştırarak eşzamanlı bağlantı sayısını ölçüyorum.
— Rob aklını başına toplar
Web istemcileri bağımsız makinelerde mi yoksa aynı makinede mi çalışıyor? (İstemci tarafında herhangi bir kısıtlamanın olup olmadığı kontrol ediliyor.)
— Jeremy McGee
3
@JeremyMcGee Ayrı makineler. Makine başına 1 istemci-sunucu bağlantısı. Ayrıca, ağın herhangi bir yerinde herhangi bir kısıtlama olmadığını biliyoruz çünkü arka uca doğrudan vurduğumuzda (bu HTTP üzerinden de olur) darboğazla karşılaşmayız.
— Rob Sobers
1
Rob, buna hiç kesin bir çözüm buldun mu?
— electronicKT

Yanıtlar:

104

Burada verilen yanıtların çoğu, ASP.net uygulamanızdan arka uç hizmetinize yapabileceğiniz giden isteklerin sayısını değil, arka uç web hizmetinize gelen isteklerin sayısına yöneliktir.

Burada istek oranınızı azaltan arka uç web hizmetiniz değil, arayan uygulamanızın aynı uç noktaya (aynı URL) kurmaya istekli olduğu açık bağlantıların sayısıdır.

Aşağıdaki yapılandırma bölümünü machine.config dosyanıza ekleyerek bu sınırlamayı kaldırabilirsiniz:

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

Elbette 50 veya 100 eşzamanlı bağlantı gibi daha makul bir sayı seçebilirsiniz. Ancak yukarıdakiler onu maksimuma kadar açacaktır. Tüm adresleri gösteren '*' yerine yukarıdaki açık sınır kuralı için belirli bir adres de belirtebilirsiniz.

System.Net.connectionManagement için MSDN Belgeleri

.NET'te ConnectManagement'ı anlamak için başka bir Harika Kaynak

Umarız bu sorununuzu çözer!

DÜZENLEME: Hata, yukarıdaki kodunuzda belirtilen bağlantı yönetimine sahip olduğunuzu görüyorum. Yukarıdaki bilgilerimi, aynı sorunu yaşayan gelecekteki sorular için uygun olduğu için bırakacağım. Ancak, en güncel sunucularda şu anda 4 farklı machine.config dosyası bulunduğunu lütfen unutmayın !

Hem 32-bit hem de 64-bit altında çalışan .NET Framework v2 ve hem 32-bit hem de 64-bit altında çalışan .NET Framework v4 vardır. Uygulama havuzunuz için seçtiğiniz ayarlara bağlı olarak, bu 4 farklı machine.config dosyasından herhangi birini kullanıyor olabilirsiniz! Lütfen tipik olarak burada bulunan 4 machine.config dosyasının tümünü kontrol edin:

  • 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
— BenSwayne
kaynak
Evet, o üssü kapattım. Yine de teşekkürler, @BenSwayne! Doğru machine.config(64 bit 4.0) değiştirdiğimi doğruladım .
— Rob aklını başına toplar
@RobSobers: Bu durumda uygulama kodundan biraz şüphelenirdim. Belki de iş parçacığı falan bitiyordur? TcpClient webservice çağrı kodunuzu bir konsol uygulamasına atabilir ve daha iyi bir istek oranı elde edip edemeyeceğinizi görebilir misiniz? Bu, IIS'ye özgü bir yapılandırma mı yoksa daha geniş bir .NET yapılandırması mı yoksa kodunuz mu olduğunu kanıtlayacaktır.
— BenSwayne
Bu satır istemci makineye giriyor mu?
— Uri Abramson
teşekkür ederim, ayarlarınız codeproject.com/Articles/133738/… 'den processModel twekaing ile birleşiyor sabit "ISAPI' C: \ windows \ Microsoft.Net \ Framework \ v2.0.050727 \ aspnet_isapi.dll 'aşağıdaki nedenden dolayı kendisini sağlıksız olarak bildirdi : 'Kilitlenme algılandı "sorunu
— Zakos
@BenSwayne aynı kavram SMTP bağlantıları için de geçerli mi? Bir toplu e-posta gönderme uygulaması tasarlıyorum, bu nedenle bu ConnectionManagement özelliği toplu posta göndermede de yararlı olacak mı ( mail.send işlevi için çoklu iş parçacığı kullanarak )?
— vibs2006
7

Sorunun oldukça eski olabileceğinin farkındayım, ancak arka ucun aynı sunucuda çalıştığını söylüyorsunuz. Bu, muhtemelen varsayılan bağlantı noktası 80'den farklı bir bağlantı noktası anlamına gelir.

"ConnectionManagement" yapılandırma öğesini kullandığınızda, varsayılan 80'den farklıysa bağlantı noktası numarasını belirtmeniz gerektiğini okudum.

BAĞLANTI: maxConnection ayarı ASP.NET'te autoConfig = false bile çalışmayabilir

İkinci olarak, varsayılan yapılandırmayı (adres = "*") kendi arka uca özel değerinizle genişletilmiş olarak kullanmayı seçerseniz, önce belirli değeri koymayı düşünebilirsiniz! Aksi takdirde, bir istek yapılırsa, önce * eşleşir ve varsayılan 2 bağlantı alınır. Aynı bölümü web.config dosyasında kullandığınızda olduğu gibi.

BAĞLANTI: <remove> ConnectionManagement için Öğe (Ağ Ayarları)

Umarım birine yardımcı olur.

— Sebastian Hek
kaynak
5

WCF tabanlı bir web hizmeti referansı kullanıyor olmanız mümkün olabilir mi? Varsayılan olarak, ServiceThrottlingBehavior.MaxConcurrentCalls 16'dır.

Servis referans davranışınızın <serviceThrottling>öğesini güncellemeyi deneyebilirsiniz

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

(Yukarıdaki ayarları tavsiye ettiğimi unutmayın.) Uygun bir öğenin nasıl yapılandırılacağıyla ilgili daha fazla bilgi için MSDN'ye bakın <behavior>.

— Ruben
kaynak
Keşke olsaydık, ama değiliz. Tüketilen hizmet başka bir makinede Apache / Python / mod_wsgi'de çalışıyor ve Rob'un da bahsettiği gibi sorun bu değil.
— Benjamin Pollack
Servis Referansları müşteri üzerindedir. İstemciniz Apache hizmetini nasıl tüketiyor?
— John Saunders
John'un dediği gibi: azaltma, web hizmetini tüketen istemcide ayarlanır. Belki de "hizmet davranışınız" ifadesi biraz yanıltıcıdır. "Servis referans davranışınız" olarak ifade edildiğinde daha anlamlı olur mu?
— Ruben
@john Bir aracılığıyla tüketilir TcpClient(hizmet, WCF / SOAP veya benzeri değil, özel ikili bloblar satar). Bu yapılandırma seçenekleri , kullanırsanız tamamen sizi etkiliyor gibi görünüyor ; bir şey mi kaçırıyorum ServiceHostTcpClient
— Benjamin Pollack
Neden "Servis Referansı Ekle" yi kullanmıyorsunuz?
— John Saunders
3

Statik DefaultConnectionLimit özelliğinin değerini programlı olarak ayarlamayı denediniz mi?

İşte bu gerçek baş ağrısı hakkında iyi bir bilgi kaynağı ... IIS 7.5, IIS 7.0 ve IIS 6.0'da ASP.NET İş Parçacığı Kullanımı, çerçeve 4.0 için güncelleştirmeler.

— Simon Mourier
kaynak
Bunun önemli olmaması gerektiğini düşünüyorum, ama yine de deneyeceğim.
— Rob aklını başına toplar
Birkaç yıl önce bu şekilde düzelttik. Eşzamanlılık sorunları yaşadık ve bu sorunu çözmüş gibiydi. Net.ServicePointManager.DefaultConnectionLimit = 1000 kullandığımız şeydir. Bağlantı sınıfları oluşturmadan ÖNCE ayarlamalısınız.
— Brain2000
2

Bu sayfanın "Diş Açma" bölümüne bakın: "Bağlantılar" bölümü ile birlikte http://msdn.microsoft.com/en-us/library/ff647786.aspx .

ProcessModel ayarınızın maxconnection niteliğini yükseltmeyi denediniz mi?

— Matt Evans
kaynak
Evet bende var. Ancak alıntı yaptığınız bu makale, konuyla ilgili diğer makalelerin bahsetmeyi ihmal ettiği ilginç bir şeye işaret ediyor: maxconnectionözniteliğin yerel web servis çağrıları için geçerli olmadığı . Bu özel durumda web hizmeti olan yerel, ancak hizmet yerel olmadığı durumlarda biz başka bir ortamda aynı sorun var.
— Rob aklını başına toplar
@RobSobers - Yukarıdaki bağlantının ikinci bir bakmaya değer olduğunu düşünüyorum. Şununla ilgili kısmı kontrol edin minLocalRequestFreeThreads- Bu alt işlem , iş parçacığı havuzundaki kullanılabilir iş parçacığı sayısı bu sayının altına düşerse localhost'tan (bir Web uygulamasının aynı sunucuda bir Web hizmetini çağırdığı) istekleri sıraya koymak için bu ayarı kullanır . Bu ayar minFreeThread'e benzer, ancak yalnızca localhost kullanan istekler için geçerlidir .
— Ahmad
@Ahmad Yup, ben de ayarladım minLocalRequestFreeThreads( soruda benimle görüşün machine.config.
— Rob Sobers
0

Web hizmeti sarf malzemesini barındıran web hizmetinde veya uygulamada veya sunucuda (apache veya IIS) tanımlanmamışsa, hataya kadar sonsuz bağlantı oluşturabilirsiniz.

— Frank Tudor
kaynak
0

performans testi yaparken, benim kullandığım ölçü RPS, yani sunucunun kabul edilebilir gecikme süresi içinde saniyede kaç istek sunabileceği.

teorik olarak bir sunucu üzerindeki çekirdek sayısı kadar isteği aynı anda çalıştırabilir ..

Sorun, potansiyel olarak binlerce rps'ye hizmet edebileceği için ASP.net'in iş parçacığı modeli gibi görünmüyor. Sorun başvurunuz olabilir gibi görünüyor. Herhangi bir senkronizasyon temelini kullanıyor musunuz?

ayrıca web hizmetlerinizdeki gecikme nedir, yanıt vermeleri çok hızlı mı (mikrosaniye içinde), değilse, eşzamansız çağrıları düşünmek isteyebilirsiniz, böylece engellemeyi sonlandırmazsınız

Bu bir şey yaratmazsa, Visual Studio veya redgate profil oluşturucusunu kullanarak kodunuzun profilini çıkarmak isteyebilirsiniz.

— np-sert
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.