# Resource optimization

### Resource usage

To run a UI Bakery instance, it's recommended to have at least **2 CPUs** and **4 GiB** of memory. For handling hundreds or thousands of simultaneous user sessions, or gigabytes of data in automation, you may need to increase these resources. It's challenging to specify the exact resource requirements, so we recommend monitoring resource usage and adjusting based on demand.

When you deploy UI Bakery using Docker Compose, each UI Bakery service will consume resources on demand. You may want to adjust resource limits for various UI Bakery services based on your specific needs. If you expect that users might trigger heavy queries leading to overuse of resources, set hard limits in the `docker-compose.yml` file, for example:

```yaml
 datasource:
    container_name: datasource
    image: cruibakeryonprem.azurecr.io/cloud/datasource:${UI_BAKERY_VERSION:-latest}
    restart: always
    env_file: .env
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1024M
```

The configuration above limits the datasource service to consuming more than 1 CPU and 1 GiB of memory. 

We recommend setting resource limits for the `datasource`, `automation`, and `python-runtime` services if you experience unpredictable loads on these services. The memory limit should be at least twice the size of the processed data.

### Replicating UI Bakery services

Not all UI Bakery services are designed to be replicated.

* Replicating is advisable for these services**:** `datasource`, `automation`, and `python-runtime`.\
  These services execute data requests or run user code. The heavier the datasource requests or the more complex the automation or python code execution, the more resources they may require. However, in most scenarios, these services do not need more than 1 GB of RAM and 1 CPU.\
  If you have a large number of concurrent requests, the better strategy is to scale them horizontally.
* The `bakery-back` service is designed to be scaled vertically.\
  If you observe high resource consumption on the `bakery-back` service, we recommend increasing the amount of RAM and CPU allocated to the service instance.
* Other services such as `bakery-gateway`, `bakery-front`, and `workbench-front` are simple NGINX applications.\
  They can handle heavy loads efficiently while maintaining low resource usage, so scaling is rarely necessary.

#### Scaling with docker compose

To accommodate numerous concurrent data sources or automation requests, you may choose to scale some of UI Bakery's services by adjusting the `docker-compose.yml` file with the replicas config:

```yaml
  datasource:
    container_name: datasource
    image: cruibakeryonprem.azurecr.io/cloud/datasource:${UI_BAKERY_VERSION:-latest}
    restart: always
    env_file: .env
    deploy:
      mode: replicated
      replicas: 4
```

#### Scaling with kubernates

To configure Kubernetes for auto-scaling, add these lines to `ui-bakery-datasource.yaml`. This will start with 2 instances of the datasource service, allowing scaling up to 4 instances if the CPU load increases.

```
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ui-bakery-datasource-hpa
  namespace: ui-bakery
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ui-bakery-datasource
  minReplicas: 2
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
```