Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Objectpooling kan in bepaalde omstandigheden zeer effectief zijn, wat aanzienlijke toename van de prestaties oplevert. Het algemene idee voor het optimaal hergebruik van objecten is om zoveel mogelijk resources te groeperen, de initialisatie te scheiden van het daadwerkelijke uitgevoerde werk, en vervolgens de poolkenmerken administratief aan te passen aan de specifieke hardware bij de uitrol. Dat wil gezegd, u moet doorgaan volgens de volgende stappen:
- Schrijf het object zodanig dat dure initialisatie en resourceverwerving worden meegerekend die voor elke client wordt uitgevoerd als vereiste voor het uitvoeren van werkelijke werkzaamheden namens de client. Schrijf zware objectconstructors om zoveel mogelijk resources te groeperen, zodat het object deze bewaart en ze onmiddellijk beschikbaar zijn wanneer clienten een object uit de pool ophalen.
- Configureer de pool op administratieve wijze om de beste balans te bereiken in beschikbare hardwarebronnen, waarbij meestal het geheugen dat is toegewezen aan het onderhouden van een pool van een bepaalde grootte, wordt ingeruild voor snellere toegang voor clients en het gebruik van objecten. Op een bepaald moment bereikt pooling afnemende rendementen en kunt u goed genoeg prestaties krijgen terwijl het mogelijke resourcegebruik door een bepaald onderdeel wordt beperkt.
Echt werk doen of middelen verwerven
Als u een onderdeel hebt dat clients kort en snel achter elkaar zullen gebruiken, waarbij een aanzienlijk deel van de tijd voor objectgebruik wordt besteed aan het verkrijgen van resources of initialiseren voordat u specifieke werkzaamheden voor de client uitvoert, is de kans groot dat het schrijven van uw onderdeel voor het gebruik van objectpooling voor u een grote winst is.
U kunt het onderdeel zo schrijven dat u in de constructor van het object zoveel mogelijk tijdrovend werk uitvoert dat voor alle clients uniform is: het verkrijgen van een of meer verbindingen, het uitvoeren van scripts, het ophalen van initialisatiegegevens uit bestanden of via een netwerk, enzovoort. Dit heeft het effect van het groeperen van elke dergelijke resource. U groepeert de combinatie van resources en de algemene toestand die noodzakelijk is om bepaalde werkzaamheden uit te voeren.
In dit geval, wanneer clients een object uit de pool krijgen, hebben ze deze resources onmiddellijk beschikbaar. Normaal gesproken gebruiken ze het object om een kleine werkeenheid uit te voeren, gegevens te pushen of op te halen, waarna het object IObjectContext::SetComplete of IObjectContext::SetAbort aanroept en retourneert. Bij snelle gebruikspatronen zoals dit voorbeeld levert pooling uitstekende prestatievoordelen op. U kunt volledig gebruikmaken van de eenvoud van het stateless automatische transactieprogrammeringsmodel en toch prestaties behalen die vergelijkbaar zijn met die van traditionele stateful componenten.
Als clients echter een object lang gebruiken telkens wanneer ze het aanroepen, is pooling minder zinvol. Het snelheidsvoordeel dat u krijgt, is marginaal naarmate de gebruikstijd toeneemt ten opzichte van de initialisatietijd. U krijgt minder rendementen die mogelijk niet de kosten rechtvaardigen van het geheugen dat nodig is om een groep actieve objecten vast te houden.
Kosten delen voor meerdere clients
Een variatie op het optimaliseren van initialisatie is dat u pooling statistisch kunt gebruiken om de kosten voor het verkrijgen van dure middelen te spreiden. Als u eenmaal de kosten van acquisitie of initialisatie hebt gemaakt en vervolgens het object opnieuw gebruikt, verdeelt u die kosten over alle clients die het object gedurende de levensduur gebruiken. Intensieve constructietijd is slechts één keer per object vereist.
Objecten vooraf toewijzen
Als u een niet-nul minimum poolgrootte opgeeft, wordt dat minimale aantal objecten gemaakt en gepoold wanneer de toepassing wordt gestart, klaar voor clients die de toepassing aanroepen.
Resourcegebruik beheren met poolbeheer
U kunt de maximale poolgrootte gebruiken om precies te bepalen hoe u resources gebruikt. Als u bijvoorbeeld een bepaald aantal databaseverbindingen hebt gelicentieerd, kunt u bepalen hoeveel verbindingen u op elk gewenst moment hebt geopend.
Wanneer u rekening houdt met clientgebruikspatronen, objectgebruikskenmerken en fysieke resources zoals geheugen en verbindingen, zult u waarschijnlijk een optimaal evenwichtspunt vinden wanneer u prestaties afstemt. Poolobjecten zullen na een bepaald punt afnemende rendementen opleveren. U kunt bepalen welk prestatieniveau u nodig hebt en dat in balans brengt met de resources die nodig zijn om dit te bereiken.
Als u prestaties wilt afstemmen wanneer u objectpooling configureert, kunt u objectstatistieken bewaken voor de onderdelen in een toepassing. Zie voor meer informatie Objectstatistieken bewaken.
Prestaties van JIT-Activated-onderdelen verbeteren
Objectpooling werkt zeer goed met de COM+ just-in-time activering dienst. Door objecten die via JIT geactiveerd worden te groeperen, kunt u de reactivering van objecten versnellen. U krijgt de voordelen van het openhouden van het kanaal door JIT-activering terwijl u de kosten voor opnieuw activeren beperkt. In dit geval kunt u pooling gebruiken om te bepalen hoeveel geheugen u wilt toewijzen aan objecten die verwijzingen actief hebben.
U zult waarschijnlijk JIT-geactiveerde onderdelen groeperen wanneer ze transactioneel zijn. Objectpooling is geoptimaliseerd voor het verwerken van transactionele onderdelen. Zie Transactionele objecten groeperenvoor meer informatie.
Verwante onderwerpen