Threadpoolsize
Hello,
Community has quite a few questions regarding threadpoolsize but no one - pega/members have been able to answer this question to the satisfaction. I've also reached out to few people in my circle but everyone has different understanding of it so it would be nice to get some official response on this.
So how does agent/threadpoolsize really works?
1. Is it 5 (default) concurrent threads per agent as in if there are 20 agents running and each agent has 5 items in the queue to process, then x 5 = 100 threads/batch requestors are processing different queues on a node? Taking example of FTSIncrementalIndexer does it then only process 5 items at a time for search indexing?
or
2. Is it regardless of number agents running, only 5 concurrent threads can be run. Considering there are so many OOTB agents does this mean agents wait for each other to finish and those 5 thread be available to others? I doubt this to be true as this would be detrimental to the app performance.
3. Is this setting in play only in the context of standard agents/queue processor?
Thanks
Pegasystems Inc.
US
Several points about agent/threadpoolsize:
1. It is per JVM (only applicable for war deployment - see #3 below for more details), in fact, the default of 5 of often too small for production env, set to 100 to start with.
2. QP is the long term replacement of agent, totally different underlying architecture (using stream/kafka), the setting has no relevance there. This new architecture is app server vendor agnostic and much more resilient among other advantages (see there for more info: https://community.pega.com/knowledgebase/articles/system-administration/queue-processor-faq)
3. If you use ear deployment, the setting has no relevance either. The actual underlying mechanism is different pending app server vendor (e.g., JBoss/Weblogic: JMS; WAS: AsyncBean).
Hope this clarifies.