Tuning OpsAny Platform Performance

To let users validate the product on a 4-core, 8 GB host, the OpsAny Community Edition ships with defaults that do not suit large-scale concurrent access or high-performance scenarios. Do not worry — the product fully supports them; a few performance optimizations are all it takes.

Optimizing base services

OpsAny stores data in MySQL, Redis, and MongoDB. Production deployments often need performance tuning, mainly of memory settings.

Tuning MySQL

The MySQL configuration file is INSTALL_PATH/conf/mysqld.cnf in the installation directory; it is mounted into the container at startup and can be adjusted.

# 1. Adjust the performance parameters
vim ${INSTALL_PATH}/conf/mysqld.cnf
max_connections = 4096

# Memory Tuning
innodb_buffer_pool_size=1024M
innodb_log_buffer_size=64M
key_buffer_size=520M
query_cache_size=520M

# 2. Restart the MySQL container
docker restart opsany-base-mysql

Tuning Redis

The Redis configuration file is INSTALL_PATH/conf/redis/redis.conf in the installation directory; it is mounted into the container at startup and can be adjusted.

# 1. Adjust the performance parameters
vim ${INSTALL_PATH}/conf/redis/redis.conf
...
# 2. Restart the Redis container
docker restart opsany-base-redis

Optimizing the PaaS platform

PaaS platform performance is mainly about the process count of each PaaS service: more processes support more concurrency.

Each paas service has a configuration directory in Supervisor configuration format; edit it. Adjusting the process counts of login and esb is usually mandatory.

Tuning the Proxy

• Tuning the Proxy service processes.

vim +2 ${INSTALL_PATH}/conf/proxy/proxy.ini
[program:opsany-proxy]
# Change the -w argument to run more processes; more processes support more managed hosts, e.g. -w 16
command=gunicorn wsgi --bind 0.0.0.0:8010 -k gevent -w 2 -n proxy --access-logfile - --error-logfile -

[program: opsany-proxy-celery]
# Change --autoscale=8,1 to add Celery processes; more processes support more concurrent tasks, e.g. --autoscale=64,16
command = /usr/local/bin/python3 /opt/opsany-proxy/manage.py celery worker -n proxy -l INFO --autoscale=8,1

• Tuning for Agent, Agent/SSH, and SSH/Agent onboarding

# If you onboard with the Agent, adjust the Master process count.
vim +267 ${INSTALL_PATH}/proxy-volume/etc/salt/master
# Change the worker process count; 3 is the minimum. If you onboard many hosts, this must be raised.
worker_threads: 3

• Restart the proxy container after the changes

docker restart opsany-paas-proxy

Tuning the WebSocket service

If Bastion Host sessions drop or problems appear under high concurrency, you must tune the WebSocket service.

vim ${INSTALL_PATH}/conf/opsany-paas/websocket/websocket.ini
[program:websocket]
# Adjust the --workers 4 count, e.g. --workers 32. Watch memory usage.
command=uvicorn --proxy-headers --host 0.0.0.0 --port 8004 asgi:application --workers 4

Restart the websocket container afterwards

docker restart opsany-paas-websocket

Tuning the paas service

# 1. Change the process count of the paas service: the number after -w is the number of processes.
 vim ${INSTALL_PATH}/conf/opsany-paas/paas/paas.ini
 [program:opsany-paas]
command=gunicorn wsgi --bind 0.0.0.0:8001 -k gevent -w 4 -n paas --access-logfile - --error-logfile -
directory=/opt/opsany/paas/paas
environment=DJANGO_SETTINGS_MODULE=settings,BK_ENV="production",PAAS_LOGGING_DIR="/opt/opsany/logs"
startsecs=0
stopwaitsecs=0
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/opt/opsany/logs/paas_paas.log

# 2. Restart the paas service
docker restart opsany-paas-paas

esb, login, appengine, websocket, and proxy follow the same pattern and are not listed individually.

Optimizing SaaS platforms

SaaS access performance is driven mainly by process count; raise it to support concurrent access.

Each application has a configuration directory containing an APPID-uwsgi.ini file, where APPID is the application ID. The example below uses unified permissions (rbac).

# 1. Change the process count of the unified permissions rbac service.
vim ${INSTALL_PATH}/conf/opsany-saas/rbac/rbac-uwsgi.ini
# Normally you only change cheaper, cheaper-initial, and processes.
# Worker
processes = 16                  # Maximum number of worker processes: 16.
threads = 2                     # Two threads per worker process.
enable-threads = true           # Enable thread support.
cheaper = 4                     # Keep at least 4 worker processes when load is low.
cheaper-initial = 4             # Start with 4 worker processes.
cheaper-algo = busyness         # Use the "busyness" algorithm to scale workers dynamically.
cheaper-overload = 20           # Add a worker when busyness exceeds 20.
cheaper-step = 2                # Change by 2 workers at a time.
cheaper-busyness-multiplier = 50 # Multiplier used to compute busyness; see the uWSGI documentation.
listen = 4096                   # Socket listen queue size: 4096.

# 2. Change the number of background Celery tasks: --autoscale=8,1 — 8 is the maximum, 1 the minimum.
vim ${INSTALL_PATH}/conf/opsany-saas/rbac/rbac-supervisor.ini
[program: rbac_celery]
command = /usr/local/bin/python3 /opt/opsany/rbac/manage.py celery worker -n rbac -l INFO --autoscale=8,1

# 3. Restart the unified permissions rbac container
docker restart opsany-saas-ce-rbac