Dwie aplikacje wyczerpują connection pools i generują connection timeouts.

Mam dwie aplikacje:

1. Client wykorzystujący WebSerwis do odpytywania bazy danych. Połączenia odbywają się za pośrednictwem SqlConnect (integratedSecurity). Każde odpytanie to nowe połączenie.
   Connection String dla webSerwisu:

Data Source=database;Initial Catalog=data_TEST;Integrated Security=SSPI;MultipleActiveResultSets=true;

2. Wokrery, łączące się z bazą za pośrednictwem nHibernate.
   Connection String dla workera:

Data Source=database;Initial Catalog=data_TEST;Integrated Security=SSPI;MultipleActiveResultSets=true;

W momencie, w którym worker, który ma większe zadanie na bazie(Prawdopodobnie ponad 1000 zapytań), aplikacja kliencka nie może nawiązać połączenia z bazą danych i webSerwis generuje błąd: connection timeout.

Próbowałem ustawić min pool (np 20), aby klient miał zawsze możliwość połączenia. Zwiększałem też ilość połączeń. Niestety w miarę zadowalające efekty miałem przy liczbie 2000 max connection pool dla workera a i tak nie zawsze wszystko działa poprawnie.

Aplikacje są na innym serwerze niż baza MsSql.

Co można zrobić pod względem optymalizacji aby mieć pewnosć, że web serwis zawsze się połączy?

Rozumiem, że dla każdego zapytania otwierasz nowe połączenie. Nie da się tego zrobić z jednym połączeniem i lecieć te 1000 zapytań?

Stara aplikacja, a workery są niby oddzielnymi aplikacjami ale łączą się z serwisami gdzie są definiowane a następnie są podłączane pod silnik nHibernate, gdzie za pomocą serwisów odwala się cały koncert. Przeróbka bebechów byłaby bardzo kosztowna...

Czyli w kodzie odpada, a connection string można zmienić? Masz jakiś config?
Można spróbować dopisać do connection string

Pooling=false;

Tak, ConnectionStringi jak najbardziej mogę zmienić. Mógłbyś mi wytłumaczyć czemu wyłączenie poolingu mogłoby pomóc?

Wychodzi na to, że w twoim przypadku nie jest tak jak powinno być w kwestii connection stringa. Jeśli connection string jest taki sam to za każdym razem jest wyciągana pula już istniejąca, nie tworzy się nowa. Widzę, że u ciebie connection stringi są te same więc jeśli wyłączysz pooling, a błąd wciąż będzie się pojawiał to problem jest kompletnie w czymś innym.

Wyłączyłem pooling w webServisie, błąd nadal się pojawia.

A to przypadkiem nie jest tak, że każda aplikacja ma swój pooling? Znaczy nawet jesli mają identyczne ConnectionStringi to nie mają po 100 connection pools?

Swoją droga worker potrafi wygenerować ponad 50 sesji w ciągu 2 minut. Nie jestem do końca pewien jak liczyć zajęcie pooli w tym wypadku. Można to jakoś realnie sprawdzić na bazie lub przy timeoucie z poziomu c#?

Nie za bardzo mam jak sprawdzić to zapytanie ale podobno wyciąga connection pool count:

SELECT COUNT(*)FROM(SELECT host_process_id FROM sys.dm_exec_sessions WHERE PROGRAM_NAME = 'MyApplicationName' GROUP BY host_process_id) AS A

Znam to zapytanie. Pokazuje mi jedno połczenie. Sprawdzałem w trakcie pracy workera. Wydaje mi się, że wtedy powinny być przynajmniej dwa połączenia. Workera i moje poprzez MenagmentStudio.

Możliwe, że nie mam wystarczających uprawnień.

No to wszystko wskazuje na to, że problem nie leży po stronie przepełnionej puli, a bardziej czasu połączenia lub dostępu do serwera SQL. Skoro nie ma opcji zajrzeć i poprawić w kodzie to trzeba sprawdzić czy ci się połączenie nie traci. Pisałeś, że aplikacje są na innej maszynie niż serwer. Czy to znaczy, że wszystkie zapytania lecą po LAN? Nie jestem pewien czy to da jakieś wiarygodne wyniki ale spróbuj puścić ping na serwer i zobacz czy pakiety się nie tracą.
PS.
Ja mam aplikację, która robi backup baz SQL i spotkałem się tylko raz z timeoutem. Nie miałem możliwości znalezienia przyczyny ale co dziwne aplikacja sypała timeoutem uruchomiona na tej samej maszynie co baza danych. Czasem się zastanawiam czy to ja już programować nie potrafię czy po prostu ten jest jakiś super wyjątkiem bo u pozostałych 20 klientów (czasem po 200 baz na jednej instacji) leci bez zająknięcia.

SSMS ma inny program name, wiec dlatego go nie widzisz w wyniku zapytania, pytanie czy masz możliwość puszczenia zapytan, na bazie podczas gdy workery rzucają timeout-y? Co możesz podejrzeć sprawdzić na serwerze DB?

A możesz żonglować użytkownikami do połączenia ? Można wymusić priorytet dla użytkowników za pomocą Resource Governor, może to wystarczy.

Panczo napisał(a):

SSMS ma inny program name, wiec dlatego go nie widzisz w wyniku zapytania, pytanie czy masz możliwość puszczenia zapytan, na bazie podczas gdy workery rzucają timeout-y? Co możesz podejrzeć sprawdzić na serwerze DB?

Nie mam pełnych uprawnień na serwerze. Zewnętrzna firma. Podejrzewam, że dlatego.

Slepiec napisał(a):

A możesz żonglować użytkownikami do połączenia ? Można wymusić priorytet dla użytkowników za pomocą Resource Governor, może to wystarczy.

Integrated Security=SSPI -- to nie jest równoznaczne z tym, że obie aplikacje jadą na tym samym użytkowniku?

Sprawdziłem za pomoca PerformanceMonitora jak wyglada obciażenie ConnectionPools i ConnectionPoolGroup. Wszystko poniżej 10 na wykresie. Zaś głowny wykres z Procesor Time'em lata jak szalony koło 80-90. Odpaliłem aplikację testującą w czasie działania workera i ProcesorTime osiągnął nawet 100 na pare sekund. Moge odważnie założyć, że procesor nie wyrabia i stąd zerwane połączenia?