Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 10. Tuning the WSGI processes
If you are seeing request failures due to long-running API processes, those API processes can benefit from tuning.
By default, IPA allocates 4 Web Server Gateway Interface (WSGI) processes for the API service on 64-bit systems. This default limitation to 4 processes is implemented for memory conservation purposes. Increasing the number of the WSGI processes allows more requests to be accepted at the expense of higher CPU use and memory consumption. By default, IPA uses approximately 100 to 110MB of resident memory for the API per WSGI process. With tuning this to 16 processes, which is the recommended limit, the amount is approximately 1.3GB.
Procedure
Modify the processes value in the
/etc/httpd/conf.d/ipa.conffile:WSGIDaemonProcess ipa processes=<4> threads=1 maximum-requests=500 \
Any of the longer-running API endpoints can benefit from tuning. This tuning decision is for the user to make.
For example, an OpenStack installation consists of several controllers containing multiple services. Each service requests a certificate so that all internal communication occurs over Transport Layer Security (TLS). When installing or refreshing a controller or compute node, these certificates can be requested or refreshed. In scenarios involving multiple controllers or compute nodes, the volume of certificate requests can become considerable. These requests are automated, so they happen at or nearly at the same time. Increasing the number of the WSGI threads allows the installation to complete.
10.1. Optimizing CPU usage for improved IPA server performance
When encountering performance limitations during high-volume certificate issuance tasks, tuning the CPU and Web Server Gateway Interface (WSGI) process counts can significantly enhance an IPA server’s capability to handle simultaneous requests.
With a server configured with 4 CPUs and 70 clients requesting 7 certificates each (490 certificates in total), server timeouts occured as the request volume exceeded the server’s processing capacity.
Increasing the CPU count to 8 and matching the WSGI process count to 8 raised the certificate handling capacity to 630 certificates, a 28% increase over the 4 CPU configuration, despite a 100% increase in CPU count. Further increasing the CPU count to 16 showed no additional performance gains with only 8 WSGI processes. However, by increasing the WSGI process count to 16, the server processed 770 certificates with 110 clients, reflecting a 22% improvement over the 8 CPU setup.
On average, doubling the number of CPUs resulted in a 25% increase in certificate issuance capacity, as long as the WSGI processes were tuned accordingly. This emphasizes the need to scale both CPU and WSGI processes together to prevent bottlenecks and optimize server performance.
