The current maximum launchable AFP3 threads is 2046.

But, humm, I guess that in many cases the hardware resources of the machine are over-loaded first.
And in our experiences it's absolutely okay run approx. ten instances at the same time. That is actually more than enough under normal conditions while processing incoming HTTP requests.

Here's a success story of an AFP user (taken from the English newsgroup):

In fact, it's quite satisfying to just watch the status monitor in the control center steadily ticking up new hits. AFP is so fast that the vast majority of hits all occur in the same thread. I have six threads running but only five have ever been used. During working hours there is on average one hit every second. Nevertheless there are few cases were two hits occur so closely that AFP has to send one of them to a second thread. This is amazing considering some of the programs that are being carried out. Of the 450000 hits, 440000 are all on one thread and the rest are distrubuted in diminishing numbers on the next four threads. My guess is that AFP could easily manage much higher work loads than ours, like several hits per second on a single machine.

So, as you hopefully read - one thread handled 440.000 request out of 450.000 - isn't that amazing?

Okay, but if your application runs more complex data or file operations that take too long, then I assume it would be best to ask yourself some questions:

• Are there still any possible optimizations?
• Is there any static data that could be cached (within the user's session)?
• Could the whole process be split in several steps?

Before increasing the count of instances check your application again and maybe you could do some re-factoring to improve performance...

Enjoy AFP FAQ, JoKi

PS: We changed the language-depended template handling of this site already twice. ;-)