[.NET WCF] Service instancing en memory usage

[NickThissen]

Ik heb al een tijdje een WCF service draaien, met bijbehorende Windows clients die daar naar verbinden. Dit is allemaal redelijk gehaast geprogrammeerd en ik heb me destijds niet veel verdiept in de verschillende mogelijkheden van WCF. De service heeft lang prima gedraaid dus had ik er geen omkijk naar.

Nu echter lijkt het wat populairder te worden, er draaien meer clients en nu lijk ik in IIS tegen een virtual memory limit aan te lopen. Ik weet het nog niet helemaal zeker, maar ik denk dat het probleem is dat ik veel te veel instances van de service continue in memory hou, ook al is daar niet echt een reden toe.

Ik weet nu dat ik kan kiezen tussen drie manieren waarop de instancing gedaan wordt:
1. PerCall: nieuwe instance voor elke call
2. PerSession (default, deze gebruik ik dus momenteel): een instance per sessie die expliciet afgesloten met worden.
3. Single: een enkele instance voor alle clients.


Ik heb mezelf ervan overtuigd dat PerSession niet goed is voor mijn service. Het typische gebruik van de client applicatie is om tijdens Windows startup een keer te verbinden, en daarna vrijwel niks meer te doen. Af en toe zal er een call gemaakt worden naar de service, misschien een paar keer per dag. Met de PerSession instancing als ik het goed begrijp worden er dus wel voor alle clients een nieuwe instance gemaakt en die blijft dus open staan, ook al wordt er bijna geen gebruik van gemaakt.

De vraag is nu echter: welke keuze is dan wel juist? Ik kan me voorstellen dat PerCall ook niet ideaal is vooral als er veel mensen tegelijk willen verbinden (dit komt af en toe voor). Wat gebeurt er als er ineens teveel mensen gaan verbinden? In dat geval raak ik waarschijnlijk ook de IIS virtual memory limiet en zal de service ook gestopt worden.

Een single instance lijkt me echter ook niet ideaal omdat ik dan zelf goed moet omgaan met concurrency. Dat wil zeggen dat ik de service helemaal zou moeten aanpassen. Als dat nodig is, so be it, maar liever niet natuurlijk.


Een antwoord wat ik al verwacht is natuurlijk: probeer het en meet wat het beste is. Maar dan kom ik bij de follow-up vraag... Hoe doe ik dat? Ik heb geen directe toegang tot mijn server, het is een shared host en ik kan hoogstens via Plesk een paar logs zien of IIS stoppen/starten.

Ik zou graag bijvoorbeeld willen loggen hoeveel virtual memory ik op dit moment gebruik (hoe dicht zit ik bij de limiet, hoe snel groeit het nadat ik de service start, etc), en hoeveel instances van de service zijn er momenteel live? Ik zie dat er performance counters zijn voor WCF, maar de resultaten zijn alleen in te zien op de server zelf, daar heb ik dus geen toegang toe voor zover ik kan vinden. Kan ik op een of andere manier in de code van mijn service zelf deze info ophalen en ergens in een database wegschrijven?

Bedankt!

[RobIII]

NickThissen schreef op maandag 25 maart 2019 @ 10:06:
Een single instance lijkt me echter ook niet ideaal omdat ik dan zelf goed moet omgaan met concurrency.

Zolang je WcfService geen state heeft is dat toch geen probleem?

Maar als ik jou was zou ik eens even je code nalopen op zaken die disposed dienen te worden maar waarvoor dat niet gebeurt. Want daar zit uiteindelijk natuurlijk je probleem.

NickThissen schreef op maandag 25 maart 2019 @ 10:06:
Hoe doe ik dat? Ik heb geen directe toegang tot mijn server, het is een shared host en ik kan hoogstens via Plesk een paar logs zien of IIS stoppen/starten.

Je kunt toch een testomgeving gebruiken (en als je die (nog) niet hebt: optuigen)? En dan eerst 't probleem proberen reproduceren en dan gaan kijken naar wat de oplossing is. Hier ontkom je sowieso niet aan als je een beetje fatsoenlijk wil kunnen werken; je werkt anders echt in 't donker met een aansteker in je hand die continue je duim brandt.

NickThissen schreef op maandag 25 maart 2019 @ 10:06:
Ik zou graag bijvoorbeeld willen loggen hoeveel virtual memory ik op dit moment gebruik (hoe dicht zit ik bij de limiet, hoe snel groeit het nadat ik de service start, etc), en hoeveel instances van de service zijn er momenteel live?

Kijk eens naar https://www.app-metrics.io/ ?

[ Voor 37% gewijzigd door RobIII op 25-03-2019 10:19 ]

[Hoogie2004]

NickThissen schreef op maandag 25 maart 2019 @ 10:06:
Ik zou graag bijvoorbeeld willen loggen hoeveel virtual memory ik op dit moment gebruik (hoe dicht zit ik bij de limiet, hoe snel groeit het nadat ik de service start, etc), en hoeveel instances van de service zijn er momenteel live? Ik zie dat er performance counters zijn voor WCF, maar de resultaten zijn alleen in te zien op de server zelf, daar heb ik dus geen toegang toe voor zover ik kan vinden. Kan ik op een of andere manier in de code van mijn service zelf deze info ophalen en ergens in een database wegschrijven?

Als het een shared host is verwacht ik niet dat je rechten-wise bij die counters zou mogen vanuit je proces... Dus vanuit code uitlezen lijkt me niet echt haalbaar.

NickThissen schreef op maandag 25 maart 2019 @ 10:06:
Nu echter lijkt het wat populairder te worden, er draaien meer clients en nu lijk ik in IIS tegen een virtual memory limit aan te lopen. Ik weet het nog niet helemaal zeker, maar ik denk dat het probleem is dat ik veel te veel instances van de service continue in memory hou, ook al is daar niet echt een reden toe.

Ik weet nu dat ik kan kiezen tussen drie manieren waarop de instancing gedaan wordt:
1. PerCall: nieuwe instance voor elke call
2. PerSession (default, deze gebruik ik dus momenteel): een instance per sessie die expliciet afgesloten met worden.
3. Single: een enkele instance voor alle clients.

Je moet zien te bewijzen dat die memory limit het probleem is, en dan uitzoeken waar al die memory door wordt vastgehouden. Uitzoeken wat het echte onderliggende issue is is stap 1, anders doe je alleen aan symptoombestrijding. Je kunt eventueel lokaal ook prima testen wat de overhead is in memory en of je geen memory-leaks hebt ofzo.

Wat is de reden dat je client nu een sessie bezet houdt, als er maar een paar keer per dag verkeer is? Het klinkt als een scenario waarbij de client op een bepaald moment wil kijken of er updates zijn, en op dat moment verbinding zoekt.

Als oplossing zou je dan eventueel de client kunnen aanpassen om de sessions correct te gebruiken (dus openen / sluiten o.i.d.), om zo je server te ontlasten, of de server switchen naar PerCall instances om te zien of dat helpt.

[NickThissen]

RobIII schreef op maandag 25 maart 2019 @ 10:16:
[...]

Zolang je WcfService geen state heeft is dat toch geen probleem?

Maar als ik jou was zou ik eens even je code nalopen op zaken die disposed dienen te worden maar waarvoor dat niet gebeurt. Want daar zit uiteindelijk natuurlijk je probleem.

Is het geen probleem als bijvoorbeeld:
- client 1 vraagt om data, service moet even de database benaderen, duurt bijv 3 seconden.
- client 2 vraagt ondertussen om dezelfde data.

Wordt client 2 nu gewoon in de wacht gezet en duurt zijn call tot ~6 sec? In dat geval is het misschien nog wel ok. Maar liever laat ik meerdere instances van de service tegelijk lopen, tot zover mogelijk binnen de memory limits dan.

Ik heb al lopen zoeken naar dingen die memory onnodig vast houden maar kan niks vinden. Zou het niet kunnen dat het puur openhouden van de service al zoveel memory kost, of zou dat "niks" moeten kosten als de service instance zelf geen (of weinig) resources in memory heeft? Ik neem aan dat er flink wat overhead zit puur in de service zelf.

RobIII schreef op maandag 25 maart 2019 @ 10:16:
[...]
Je kunt toch een testomgeving gebruiken (en als je die (nog) niet hebt: optuigen)? En dan eerst 't probleem proberen reproduceren en dan gaan kijken naar wat de oplossing is. Hier ontkom je sowieso niet aan als je een beetje fatsoenlijk wil kunnen werken; je werkt anders echt in 't donker met een aansteker in je hand die continue je duim brandt.

Tsja, klopt natuurlijk, maar dan moet ik ook iets verzinnen om al mijn clients te simuleren want die heb ik natuurlijk niet in de test omgeving, en juist hun connections zorgen dat het probleem optreedt. Daar gaat veel tijd in zitten en ondertussen heb ik liever een oplossing die misschien niet ideaal is maar wel snel online kan.

RobIII schreef op maandag 25 maart 2019 @ 10:16:
[...]
Kijk eens naar https://www.app-metrics.io/ ?

Bedankt, ga ik proberen!

[NickThissen]

Hoogie2004 schreef op maandag 25 maart 2019 @ 10:20:
[...]

Je moet zien te bewijzen dat die memory limit het probleem is, en dan uitzoeken waar al die memory door wordt vastgehouden. Uitzoeken wat het echte onderliggende issue is is stap 1, anders doe je alleen aan symptoombestrijding. Je kunt eventueel lokaal ook prima testen wat de overhead is in memory en of je geen memory-leaks hebt ofzo.

Zoals ook tegen Rob: dit is natuurlijk de goeie manier maar kost tijd, en ik hoop dat ik veel sneller iets kan vinden wat (tijdelijk) werkt.

Hoogie2004 schreef op maandag 25 maart 2019 @ 10:20:
[...]

Wat is de reden dat je client nu een sessie bezet houdt, als er maar een paar keer per dag verkeer is? Het klinkt als een scenario waarbij de client op een bepaald moment wil kijken of er updates zijn, en op dat moment verbinding zoekt.

De reden is omdat het zo geprogrammeerd is. Mijn client verbind met de service bij het opstarten en sluit de verbinding pas als de client weer sluit. Dit is inderdaad niet goed omdat de client 99% van de tijd niks zit te doen.

Ik zou inderdaad ook het probleem op de client kunnen fixen en voor elke call (of misschien na een tijd van inactivity) de connectie te sluiten. Ik denk echter dat het fundamentele probleem in de service zelf zit, de service zou eigenlijk niet open moeten blijven omdat dat gewoon meestal niet nodig is. Het oplossen op de client klinkt ook als een bandaid. Maar misschien moet ik beide gebruiken...

[RobIII]

NickThissen schreef op maandag 25 maart 2019 @ 15:46:
Is het geen probleem als bijvoorbeeld:

Euhm, ja, misschien wel. Misschien niet. Dat weet jij als het goed is. Jij stelt de requirements op

NickThissen schreef op maandag 25 maart 2019 @ 15:46:
Wordt client 2 nu gewoon in de wacht gezet en duurt zijn call tot ~6 sec?

Nou wil ik niet heel flauw zijn, maar ik heb net létterlijk in 45 seconden dit gedaan:

• VS Starten
• New WCF Service Application Project
• In de Service1.svc in de method GetDataUsingDataContract een Thread.Sleep(5000); gegooid
• [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] op de Service1 class gemikt.
• Het project gestart
• Een tweede instance van de WcfTestClient gestart
• Op beide instances de call gedaan en gekeken wat 't effect was

Dat kun jij ook Dit uittypen (en jouw vraag stellen) duurde geheid langer.

NickThissen schreef op maandag 25 maart 2019 @ 15:46:
Ik heb al lopen zoeken naar dingen die memory onnodig vast houden maar kan niks vinden.

Meten == weten. Wat zegt je profiler?

NickThissen schreef op maandag 25 maart 2019 @ 15:46:
Zou het niet kunnen dat het puur openhouden van de service al zoveel memory kost, of zou dat "niks" moeten kosten als de service instance zelf geen (of weinig) resources in memory heeft? Ik neem aan dat er flink wat overhead zit puur in de service zelf.

Je doet nogal wat aannames en bent véél te vaag. "Puur openhouden van de service" zegt he-le-maal niks, want we weten niet wat je service doet. Dan zijn daar dus ook geen zinnige uitspraken over te doen

NickThissen schreef op maandag 25 maart 2019 @ 15:46:
Tsja, klopt natuurlijk, maar dan moet ik ook iets verzinnen om al mijn clients te simuleren want die heb ik natuurlijk niet in de test omgeving, en juist hun connections zorgen dat het probleem optreedt. Daar gaat veel tijd in zitten

Weer een klusje van 45 seconden:

• Start VS
• New Console project
• Add Reference naar je WCF service
• Parallel.For een bult connecties tegen je WCF service aan.

C#:

Parallel.For(0, 10, (i) => {
    using (var c = new Service1Client())
    {
        Console.WriteLine($"Request {i} starting");
        c.GetDataUsingDataContract(new CompositeType { BoolValue = true, StringValue = "Test" });
        Console.WriteLine($"Request {i} complete");
    }
});

[ Voor 9% gewijzigd door RobIII op 25-03-2019 16:05 ]

[NickThissen]

Helaas heb ik op het werk geen toegang tot VS maar wel af en toe 5 minuutjes om tweakers te lezen

Je hebt gelijk natuurlijk, maar het kost op een realistische service wel iets meer tijd. Er zijn natuurlijk tal van methods die allemaal andere dingen doen, databases waar de service mee moet praten die ik niet lokaal heb, liefst test ik ook een iets realistischer scenario gebaseerd op typisch aantal connecties (dus niet 500 tegelijk maar eerder 5 per seconde over een langere tijd).

Allemaal wel te doen maar dit blijft een hobby project dat ik ook maar in de avonduurtjes er bij doe, dus dan gaat het al gauw dagen kosten voor ik de oplossing gevonden heb.

Ondertussen verwacht ik dat het probleem in mijn instancing zit en dat ik daar tijdelijk een bandaid kan toepassen zodat de service in ieder geval weer live kan.


Maar ik heb in ieder geval weer genoeg om te proberen. Thanks!

[RobIII]

NickThissen schreef op maandag 25 maart 2019 @ 16:11:
Je hebt gelijk natuurlijk, maar het kost op een realistische service wel iets meer tijd.

De vraag die ik beantwoordde ging over wat een SingleInstance nou precies deed als een request nog bezig was terwijl er een tweede binnen kwam Dat is dus zo getest (of je leest gewoon de documentatie ).

NickThissen schreef op maandag 25 maart 2019 @ 16:11:
Je hebt gelijk natuurlijk, maar het kost op een realistische service wel iets meer tijd. Er zijn natuurlijk tal van methods die allemaal andere dingen doen, databases waar de service mee moet praten die ik niet lokaal heb, liefst test ik ook een iets realistischer scenario gebaseerd op typisch aantal connecties (dus niet 500 tegelijk maar eerder 5 per seconde over een langere tijd).

Dan heb je 't dus specifiek weer over (te veel) memory usage. En daar heb je dus een profiler voor

NickThissen schreef op maandag 25 maart 2019 @ 16:11:
Ondertussen verwacht ik dat het probleem in mijn instancing zit en dat ik daar tijdelijk een bandaid kan toepassen zodat de service in ieder geval weer live kan.

Dat kan maar wat wil je nou dan dat wij zeggen zonder intieme kennis van je project te hebben (lees: zonder te weten wat "die allemaal andere dingen doen" inhoudt)?
Als je 't snel wil weten dan verander je de InstanceContextMode en Concurrency naar je smaak en je probeert 't. Sneller dan dat kan ik je ook geen antwoord geven.

[ Voor 62% gewijzigd door RobIII op 25-03-2019 16:30 ]

[Hoogie2004]

NickThissen schreef op maandag 25 maart 2019 @ 15:50:
[...]

De reden is omdat het zo geprogrammeerd is. Mijn client verbind met de service bij het opstarten en sluit de verbinding pas als de client weer sluit. Dit is inderdaad niet goed omdat de client 99% van de tijd niks zit te doen.

Ik zou inderdaad ook het probleem op de client kunnen fixen en voor elke call (of misschien na een tijd van inactivity) de connectie te sluiten. Ik denk echter dat het fundamentele probleem in de service zelf zit, de service zou eigenlijk niet open moeten blijven omdat dat gewoon meestal niet nodig is. Het oplossen op de client klinkt ook als een bandaid. Maar misschien moet ik beide gebruiken...

Nja, je zou het (zoals Rob al zegt), prima kunnen proberen met PerCall op je server. Als ik het me goed herinner kun je dat gewoon aanpassen op de server zonder verdere wijzigingen aan je client. Je kunt daar nog steeds 1 proxy instantiëren en die gebruiken gedurende dat je Client online is.

De enige reden dat je PerSession zou gebruiken, is volgens mij als je serverside een state bijhoudt van die client, over meerdere calls heen.

[leverage010]

Is het geen probleem als bijvoorbeeld:
- client 1 vraagt om data, service moet even de database benaderen, duurt bijv 3 seconden.
- client 2 vraagt ondertussen om dezelfde data.

Wordt client 2 nu gewoon in de wacht gezet en duurt zijn call tot ~6 sec? In dat geval is het misschien nog wel ok. Maar liever laat ik meerdere instances van de service tegelijk lopen, tot zover mogelijk binnen de memory limits dan.

Klopt. Dit is een probleem als je geen Async methods exposed. Gebruik hier voor IAsyncResult. Ik trek ff wat uit een oud project voor je.

/// for future reference:
/// Methods get paired by the "Begin" and "End" keywords
/// The delegate is built to create a passable variable that represents an action
/// the Generic datatypes of the Func<T> class are built as followed:
/// InputParameterTypes, OutputParameterType
/// Example:
// Func<string ,M3OrderHeader, M3DeliveryInfo, M3CollectInfo, M3AddOrderLine[], AddOrderResult> _delegate = AddOrder
/// Input Input Input Input Input Output delegatename Operation
///
/// This delegate can be invoked by calling ".BeginInvoke(#AsyncCallbackObject#,#StateObject#)"
/// Which will call on the End#MethodName# method with the AsyncResult as an IAsyncResult object
/// For this reason, the IAsyncResult object neets to be casted to an System.Runtime.Remoting.Messaging.AsyncResult object
/// by creating a new delegate, based on the content of this casted object (content being the return from calling .AsyncDelegate on the delegate)
/// it is possible to call ".EndInvoke" with the result parameter from the method as a parameter which can be returned as the actual result in an async manner
/// an example for a simple method like IsAlive (which returns the string "true") would be as follows:

// public string IsAlive()
// {
// System.Threading.Thread.Sleep(10000);
// return "true";
// }
// public IAsyncResult BeginAsyncIsAlive(AsyncCallback asyncCallback, object state)
// {
// Func<string> _delegate = IsAlive;
// return _delegate.BeginInvoke(asyncCallback, state);
// }
// public string EndAsyncIsAlive(IAsyncResult result)
// {
// System.Runtime.Remoting.Messaging.AsyncResult typesAsyncResult = (System.Runtime.Remoting.Messaging.AsyncResult)result;
// Func<string> _delegate = (Func<string>)typesAsyncResult.AsyncDelegate;

// return _delegate.EndInvoke(result);
// }

/// 1. BeginAsyncIsAlive is called
/// 2. A delegate is created and returned as an invoked IAsyncResult object
/// 3. The IsAlive method is called, and upon completion, calls the EndAsyncIsAlive method
/// 4. the EndAsyncIsAlive method builds another delegate based on the returned ASyncResult
/// 5. The _delegate returns the EndInvoke call, which returns the completed result

gooi dat ff in je IDE dan is het wat leesbaarder.

[RobIII]

Je kunt gewoon async, await en Task gebruiken hoor ipv dat prehistorische gedoe met IAsyncResult. Of dat 't probleem van TS oplost betwijfel ik; ik quote even uit de TS: " lijk ik in IIS tegen een virtual memory limit aan te lopen". If anything dan maak je het met async maken van alle methods alleen maar erger (even aangenomen dat 't inderdaad een memory probleem is overigens hoor).

[leverage010]

RobIII schreef op dinsdag 26 maart 2019 @ 12:43:
Je kunt gewoon async, await en Task gebruiken hoor ipv dat prehistorische gedoe met IAsyncResult. Of dat 't probleem van TS oplost betwijfel ik; ik quote even uit de TS: " lijk ik in IIS tegen een virtual memory limit aan te lopen". If anything dan maak je het met async maken van alle methods alleen maar erger (even aangenomen dat 't inderdaad een memory probleem is overigens hoor).

Ja chef had hem die info dan gewoon gegeven dan.

[RobIII]

leverage010 schreef op dinsdag 26 maart 2019 @ 13:16:
Ja chef had hem die info dan gewoon gegeven dan.

Welke info?

[leverage010]

[...]

Nou wil ik niet heel flauw zijn, maar ik heb net létterlijk in 45 seconden dit gedaan:

• VS Starten
• New WCF Service Application Project
• In de Service1.svc in de method GetDataUsingDataContract een Thread.Sleep(5000); gegooid
• [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] op de Service1 class gemikt.
• Het project gestart
• Een tweede instance van de WcfTestClient gestart
• Op beide instances de call gedaan en gekeken wat 't effect was

Dat kun jij ook Dit uittypen (en jouw vraag stellen) duurde geheid langer.

Je kunt gewoon async, await en Task gebruiken

@RobIII

[RobIII]

leverage010 schreef op dinsdag 26 maart 2019 @ 14:26:
[...]


[...]


@RobIII

Euh... ergens praten we langs elkaar. Het één staat toch helemaal niet in relatie tot 't ander? Zoals ik zei is 't nog maar de vraag of async het probleem (wat een geheugenprobleem zou zijn volgens TS) gaat oplossen en daarbij ging 't over de instancemode (single/per call/per session). Dus ik zie niet hoe jij daaruit destilleert dat ik dan maar over async had moeten beginnen...

[leverage010]

Hij kaartte zijn zorgen aan met betrekking tot synchrone operaties, vervolgens kom je met een heel verhaal over hoe hij dat zelf had kunnen opzoeken. Ik maak het die kerel wat makkelijker door zelf wat tevoorschijn te vissen om hem op weg te helpen met exact dat, en vervolgens zeg je ja dat kan beter...

dan denk ik... "Kerel, had hem die info gewoon gegeven dan".

en dat is best een logische gedachtegang al zeg ik het zelf.

[RobIII]

leverage010 schreef op dinsdag 26 maart 2019 @ 16:17:
Hij kaartte zijn zorgen aan met betrekking tot synchrone operaties

De eerste die 't woord (a)synchroon liet vallen ben jij hoor? Het ging gewoon over 'operaties', of die nou synchroon of asynchroon zijn. Maar goed; laten we 't topic niet nog verder offtopic helpen. Als TS denkt dat 't asynchroon maken van de methods zijn probleem oplost weet 'ie nu dus hoe 't moet