Change Details

What/Why: We are currently focused on finding ways to improve the performance of our `function-orchestrator` service. Since tracking our heap usage through logs, we discovered we are too frequently using over 90% of the NodeJS heap limit. ([[ https://phabricator.wikimedia.org/T384883#10514431 | Ticket and notes here ]]). This week therefore, we increased [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/charts/function-orchestrator/values.yaml#18 | the Orchestrator container k8s limit to 1Gib ]]. Our usage has not change/decreased based on the logs however. We would like to consider ideas including: - Increasing the Orchestrator's CPU limit to 60ms rather than [[ https://grafana.wikimedia.org/goto/GEDK2xFHg?orgId=1 | the current 40ms ]]? If it's not too much trouble, would be great to try this out. - Increase (double) the NodeJs heap limit within the orchestrator service itself to 4096 MB? How/Next-steps: tbd How:

What/Why: We are currently focused on finding ways to improve the performance of our `function-orchestrator` service. Since tracking our heap usage through logs, we discovered we are too frequently using over 90% of the NodeJS heap limit. ([[ https://phabricator.wikimedia.org/T384883#10514431 | Ticket and notes here ]]). This week therefore, we increased [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/charts/function-orchestrator/values.yaml#18 | the Orchestrator container k8s limit to 1Gib ]]. Our usage has not change/decreased based on the logs however. We would like to consider ideas including: - Increasing the Orchestrator's CPU limit to 600ms rather than [[ https://grafana.wikimedia.org/goto/GEDK2xFHg?orgId=1 | the current 400ms ]]? If it's not too much trouble, would be great to try this out. - Increase (double) the NodeJs heap limit within the orchestrator service itself to 4096 MB? How/Next-steps: tbd How:

What/Why: We are currently focused on finding ways to improve the performance of our `function-orchestrator` service. Since tracking our heap usage through logs, we discovered we are too frequently using over 90% of the NodeJS heap limit. ([[ https://phabricator.wikimedia.org/T384883#10514431 | Ticket and notes here ]]). This week therefore, we increased [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/charts/function-orchestrator/values.yaml#18 | the Orchestrator container k8s limit to 1Gib ]]. Our usage has not change/decreased based on the logs however. We would like to consider ideas including: - Increasing the Orchestrator's CPU limit to 600ms rather than [[ https://grafana.wikimedia.org/goto/GEDK2xFHg?orgId=1 | the current 400ms ]]? If it's not too much trouble, would be great to try this out. - Increase (double) the NodeJs heap limit within the orchestrator service itself to 4096 MB? How/Next-steps: tbd How: