There's no simple answer here.
How much overall method server heap and how many overall CPU cores your user community requires depends on many things beyond the number of users, e.g. their level of activity, how concentrated this activity is to portions of the day (e.g. do they all pound on the server at the start and end of the business day), what types of operations they do, and how big/complicated is the data involved in these operations, and so on. I believe there are overall sizing guidelines out there.
Since it takes a bit of time to start a method server and it is possible for a method server to die or hang in cases, you'll generally want at least 2 foreground method servers in any production environment.
Whether one has just 2 method servers or more than that is also not an especially simple answer. Each additional method server brings additional memory overhead (e.g. its own JVM, its own copies of class data, its own class statics and singletons, its own caches, and so on) and, to a lesser extent, its own additional CPU overhead (e.g. just-in-time compilation of the same classes in multiple JVMs, additional cache coordination, etc). Each additional method server also splits up the available memory, thus limiting the maximum transaction size. On the other hand, splitting up available memory also prevents one extraordinarily aberrant transaction from using an overt share of overall server memory and improves availability in the rare case where multiple method servers are incapacitated. Probably the biggest reason to have more than 2 method servers, however, is to overcome any scaling limits within a single method server. These limits may be in the JVM itself, e.g. the garbage collector may not scale well to extremely large heaps (particularly in older JVMs) or some PTC code may have an (unintentional) scalability bottleneck (e.g. too much locking causing an unnecessary slow down under high concurrency within a single method server). The tradeoffs are complex and will be influenced by the distribution (type, size, and frequency) of operations being performed by the users. That said, newer versions of Windchill and newer JVMs seem to handle larger method servers better than older versions did.
As for wt.method.loadbalance.activeContext, it has a relatively minor influence in recent releases -- as it only impacts RMI, not HTTP(S) traffic. It should already have a reasonable default in recent Windchill versions, though it may need some tweaking in cases.
