This is old article - but still relevant :
Siteminder Spiral of Death (or why do I have all these socket 32 errors in my policy server logs)
It is best to run some load testing, with trace logging, look for the current bottleneck, (Siteminder Policy Trace Analysis ) make adjustments to try fix that bottleneck, then re-run the load test - find next bottleneck.
If all 16 threads are 100% busy, that may be a bottleneck ,but also those 16 threads may all be waiting for a LDAP connection, and is so, then it is the LDAPBank connection pool that is current bottleneck.
For the rule of X threads per CPU, the assumption there is that the threads will be mostly busy, whereas in my experience most policy server worker threads are idIe waiting for some backend service (ldap or similar ) to complete - so the number of threads needed was not based on CPU just on how many active requests you needed to have to put the right load pressure onto the backend ldap (or other) server.
The main bottleneck for policy servers was usually the number of ldapbanks (a default install can give you 1, whereas better throughput will generally requires more, and for optimal throughput required #ldapbanks size close to work-thread pol size (due to way a locking condition works) ). -
But running load test and analysis is the best way to determine what is the current bottleneck:
Change setup of LDAP User Store screen to allow entry of LDAP connection pool size.
And testing failure conditions is also a must - an ldap going slow for example may cause your system to ground to a halt - so best to test that so you know how it will fail.
Cheers - Mark