Initiele connectie naar SQL server traag, daarna snel

[Bielie993]

Hoi Tweakers,

Ik ben al een paar dagen aan het worstelen met het volgende probleem:

Ik heb een applicatie die verbinding maakt via een connection string naar MS SQL Server 2014. Deze applicatie staat op heel veel plekken in de zelfde vorm bij verschillende klanten. Overal gaat het goed behalve bij deze klant.

Op de PC's staat de applicatie geïnstalleerd welke verbinding maakt naar een SQL server ergens in het netwerk. Het opzetten vna de verbinding duurt soms meer dan 1 minuut. Maar zodra hij 1x verbinding maakt loopt het vlot. Als de PC een tijdje niet gebruikt is of de PC opnieuw opgestart wordt duurt het weer langer.

Om te troubleshooten heb ik geprobeerd om een lokale instantie van SQL te installeren op de machine. De verbinding loopt nu iets sneller, maar nog steeds onacceptabel (10-15 seconden). Dit lijkt er dus op dat er lokaal ook iets gebeurd waardoor (alle) sql connecties er langer over doen?.

Ik heb alles zonder DNS geprobeerd, maar het is nog steeds traag.

Ik heb de hardware vervangen van zowel de server als de cliënt. Bij het wijzigen vna de server hardware is SQL ook opnieuw geinstalleerd (mixed mode, met named pipes en tcp ip op een vaste poort).

Windows opnieuw geïnstalleerd op de clients. Netwerk adapter drivers geupgrade en gedowngrade.

De slaapstand staat uit op de clients.

Pingen naar server gaat wel snel.

Ik beheer het domein waar de PC in zit niet zelf, dus die instellingen kunnen ook nog een probleem vormen. (Maar aan welke instellingen moet ik dan denken? NAP?)

Het moet bijna wel in de authorisatie laag zitten of er is een soort connection pool die moet woden opgezet die na een tijdje wegvalt.

Mijn vraag is: Is er hier iemand die een soortgelijk probleem heeft of meer snapt van alle lagen die clients doorlopen om bij de server te komen. Ik ben het spoor bijster en google heeft weinig resultaat. (Alles al geprobeerd van de gevonden oplossing, maar geen werkt.)

[Voor 7% gewijzigd door Bielie993 op 23-11-2018 10:21]

[lier]

Kan je, afgezien van je credentials, de connectionstring hier posten?
Is er een reden dat je het hier post in plaats van in Softe goederen

[Bielie993]

lier schreef op vrijdag 23 november 2018 @ 10:47:
Kan je, afgezien van je credentials, de connectionstring hier posten?
Is er een reden dat je het hier post in plaats van in Softe goederen

Data source = server;Initial Catalog = Database;User ID = username;Password = password;Persist Security Info=True;Connection Timeout=30;Max Pool Size = 5000

Ik heb hem hier gepost, omdat ik denk dat het een netwerk probleem is en niet perse een software probleem. Maar ik denk dat het in dit geval een beetje grijs gebied is. Dus als hij verkeerd staat mijn excuses.

[lier]

Geen probleem, probeer alleen mee te denken!

Zou je in plaats van server óf de FQDN óf het IP adres willen testen?

[Bielie993]

lier schreef op vrijdag 23 november 2018 @ 11:16:
Geen probleem, probeer alleen mee te denken!

Zou je in plaats van server óf de FQDN óf het IP adres willen testen?

Dit had ik inderdaad al getest, maar het probleem blijft hetzelfde.

[Bierkameel]

Om switches, firewalls en routers uit te sluiten zou je eens een client aan de switch kunnen hangen waar die server op zit, als het dan snel is zit het ergens in het netwerk.

[Marco1994]

Is het niet zi dat die een connection pool vult met 5000 verbindingen en daar op wacht.

[Gomez12]

Wat heb je nou exact gedaan? Want in het onderstaande heb je het erover dat je hardware van server en client hebt vervangen, maar windows is alleen opnieuw geinstalleerd op de client? Wat is er dan op de server gebeurt?

Bielie993 schreef op vrijdag 23 november 2018 @ 10:10:
Ik heb de hardware vervangen van zowel de server als de cliënt. Bij het wijzigen vna de server hardware is SQL ook opnieuw geinstalleerd (mixed mode, met named pipes en tcp ip op een vaste poort).

Windows opnieuw geïnstalleerd op de clients. Netwerk adapter drivers geupgrade en gedowngrade.

Probeer anders eens vanaf de sql server naar en de client en de ad-master te pingen op de fqdn?
Want als je sql server staat te authenticeren tegen de ad aan dan kan daar ook je vertraging inzitten.

[Ben(V)]

10-15 seconden vertraging kunnen nooit in het netwerk zitten als het gewoon lokaal is, daar moet je het echt niet zoeken.

Het lijkt wel op of hij eerst de hele SQL-server op moet starten.
Heeft de server wel voldoende geheugen en staat hij niet als een gek te swappen?

[Out.of.Control]

Wordt er wellicht geprobeerd in eerste instantie via IPv6 te verbinden? En dat er na de time-out wordt overgegaan op IPv4 dat wel snel werkt?

[MAX3400]

Samenvatting startpost:

- alle hardware vervangen (client en servers)
- alle software opnieuw geinstalleerd
- reproduceerbaaar traag op dezelde momenten / situaties

Wat @Bierkameel zegt, is best een goede test; hang eens een client direct aan de server. Misschien wel met een unmanaged switch (en dus ook een connectie naar AD ofzo).

@Anoniem: 19347 Een mixed login op SQL synct toch zelf al? Juist om te voorkomen dat als AD er niet is, dat je niet bij SQL kan?

@Bielie993 heb je mixed logins of native sql accounts? Sterker nog; treedt het probleem ook op als je (ter test!!!!!) een connectie legt met als user/pass het service-account van de instance zelf?

Bielie993 schreef op vrijdag 23 november 2018 @ 10:54:
[...]
Data source = server;Initial Catalog = Database;User ID = username;Password = password;Persist Security Info=True;Connection Timeout=30;Max Pool Size = 5000

En als je een np-connectie opzet? Zoals ongeveer beschreven in https://docs.microsoft.co...ipes?view=sql-server-2014

When a new connection is opened, if the connection string is not an exact match to an existing pool, a new pool is created. It is normal that the first database connection takes 4-10 seconds.

Kan je dit ook dubbelchecken? Dat je connectionstring wel overeenkomt met je pool settings?

[Voor 38% gewijzigd door MAX3400 op 23-11-2018 16:10]

[Xiphalon]

Wat is je max MTU naar de server? Kan dat netjes worden bepaald? Een van de eerste packets is iets van 1498 bytes, waardoor als je je MTU niet direct goed bepaald is er soms geen connectie tot een trage opbouw ontstaat.

Ook zou ik je DNS checken, misschien dat de primaire server een timeout geeft waarna de secundaire het wel weet.

[_JGC_]

Doet de server toevallig een reverse DNS controle op het IP van de cliënt? Wat als je die in de hostsfile zet?

[The Eagle]

Doe ff:
- telnet op poort 1433 (iirc) naar de server. Kijken of de connectie gewoon open staat
- Check op je authenticatie. Is dat met local accounts of met AD accounts?
- indien AD acounts: maak een local account aan en log daar mee in. Gaat het dan wel snel --> Zo ja: je authenticatiemechanisme is de bottleneck