Performance tuning

This section contains various configurations that can improve the performance, some might not be appropriate for your environment, but all these options are known to have an impact on performance.

Threads

This is probably the most important configuration for your system, particularly for benchmarking. The default configurations are good for most systems, but can obviously be improved. The relevant settings are:


CONFIG proxy.config.exec_thread.autoconfig INT 0
CONFIG proxy.config.exec_thread.autoconfig.scale FLOAT 2.0
CONFIG proxy.config.exec_thread.limit INT 5

CONFIG proxy.config.accept_threads INT 1

CONFIG proxy.config.cache.threads_per_disk INT 8

CONFIG proxy.config.task_threads INT 2

The first three control the number of network threads, which are the threads primarily responsible for handling and processing all requests.

The next configuration controls the accept thread configuration, 1 is almost always the best, but some times 0 (moves accept back to the net-threads), or 2-3 might be optimal. It's really application specific.

Cache threads are setup per disk, 8 is usually good, but on very active system, with lots of disk activity, 16 or more threads might be necessary. These threads are blocking on disk I/O, so having more of these generally won't make the system a lot slower (but don't go overboard). Going with too few threads obviously won't let you use the full capacity of the disk's I/O capacity.

Finally, there's a set of background task threads, threads meant to off load the normal net-threads with mundane tasks. This is currently only mildly used by the ATS core, but more and more tasks are moved over to these threads as we make progress. This allows the net-thread to both serve more requets, and do so at less latency in the responses. Additionally, plugins are encouraged to use this pool of threads for similar tasks. This means that the number of these threads depends on not only which version of ATS you are using (v3.0 only lightly uses these threads), but also what plugins you are using. You will simply have to watch these threads, and see if they are becoming bottlenecks, and then increase this as necessary.

 

Network related options

 

HTTP related options

 

Hacking: 

Comments

Re: Performance tuning

Would be nice to see some more details on any hueristics/guidelines for tuning the
threads related parameters. Is there any math to it? Or are they more of
change->test->tune cycle..

thanks

Re: Performance tuning

It's not too bad, typically, 1 to 1.5 thread per core element seems to be optimal, perhaps with an extra thread just for shits and gigglesl. What can skew the results is the presence of Hyper Threading, our autoscaling (in 3.0.0, I've fixed it on trunk if you have the hwloc library installed) creates too many threads. This is because each HT enabled core shows up as two physical cores, and that really isn't right.

Now, this is for performance benchmarking, there might be other reasons to have more threads, e.g. . if there's some computational heavy stuff going on in a plugin, it might make sense to have more threads to get fewer active connections per worker thread.