streamalism.org

1. Inleiding

In deze zelfstudie bekijken we de configuratie van threadpools voor Java-webtoepassingsservers zoals Apache Tomcat, Glassfish Server en Oracle Weblogic.

2. Server Thread-pools

Server-threadpools worden gebruikt en beheerd door een webtoepassingsserver voor een geïmplementeerde toepassing. Deze threadpools bestaan ​​buiten de webcontainer of servlet, zodat ze niet onderhevig zijn aan dezelfde contextgrens.

In tegenstelling tot toepassingsthreads, bestaan ​​serverthreads zelfs nadat een geïmplementeerde toepassing is gestopt.

3. Apache Tomcat

Ten eerste kunnen we de server-threadpool van Tomcat configureren via de Uitvoerder configuratieklasse in ons server.xml:

minSpareThreads is de kleinste die het zwembad zal zijn, ook bij het opstarten. maxThreads is de grootste die het zwembad zal zijn voordat de server begint met het in de wachtrij plaatsen van verzoeken.

Tomcat stelt deze standaard in op respectievelijk 25 en 200. In deze configuratie hebben we de threadpool iets kleiner gemaakt dan de standaard.

3.1. Ingebouwde Tomcat

Evenzo kunnen we een ingesloten Tomcat-server voor Spring Boot wijzigen om een ​​threadpool te configureren door een applicatie-eigenschap in te stellen:

server.tomcat.max-threads = 250

Vanaf Boot 2.3 is de eigenschap gewijzigd in:

server.tomcat.threads.max = 250

4. Glasvis

Laten we vervolgens onze Glassfish-server updaten.

Glassfish gebruikt een admin-commando in tegenstelling tot het XML-configuratiebestand van Tomcat, server.xml. Vanaf de prompt voeren we uit:

create-threadpool

We kunnen toevoegen aan create-threadpool de vlaggen maxthreadpoolsize en minthreadpoolsize. Ze werken op dezelfde manier als Tomcat minSpareThreads en maxThreads:

--maxthreadpoolsize 250 --minthreadpoolsize 25

We kunnen ook specificeren hoe lang een thread inactief kan zijn voordat deze terugkeert naar de pool:

--idletimeout = 2

En dan geven we aan het einde de naam van onze threadpool:

asadmin> create-threadpool --maxthreadpoolsize 250 --minthreadpoolsize 25 --idletimeout = 2 threadpool-1

5. Weblogic

Oracle Weblogic geeft ons de mogelijkheid om een ​​zelfafstemmende threadpool aan te passen met een WorkManager.

Net als bij thread-wachtrijen, beheert een WorkManager een thread-pool als een wachtrij. De WorkManager voegt echter dynamische threads toe op basis van realtime doorvoer. Weblogic voert regelmatig analyses uit op de doorvoer om het gebruik van threads te optimaliseren.

Wat betekent dit voor ons? Het betekent dat hoewel we de threadpool kunnen wijzigen, de webserver uiteindelijk zal beslissen of er nieuwe threads worden voortgebracht.

We kunnen onze threadpool configureren in de Weblogic Admin Console:

Updaten van het Zelfinstellende minimale draadpoolgrootte en Zelfinstellende draad Maximale grootte van het zwembad waarden bepalen de min en max grenzen voor de WorkManagers.

Let op de Max. Tijd vastgelopen draad en Timerinterval vastgelopen draad waarden. Deze helpen de WorkManager om vastgelopen threads te classificeren.

Soms kan een langlopend proces een opeenhoping van vastzittende threads veroorzaken. De WorkManager zal ter compensatie nieuwe threads uit de thread-pool spawnen. Elke update van deze waarden kan de tijd verlengen voordat het proces kan worden voltooid.

Vastzittende threads kunnen wijzen op codeproblemen, dus het is altijd het beste om de hoofdoorzaak aan te pakken in plaats van een tijdelijke oplossing te gebruiken.

6. Conclusie

In dit korte artikel hebben we gekeken naar meerdere manieren om threadpools van toepassingsservers te configureren.

Hoewel er verschillen zijn in hoe de applicatieservers de verschillende threadpools beheren, zijn ze geconfigureerd met vergelijkbare concepten.

Laten we tot slot onthouden dat het wijzigen van configuratiewaarden voor webservers geen geschikte oplossingen zijn voor slecht presterende code en slechte applicatieontwerpen.