You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the motivation for the change?
This will increase the throughput of I/O intensive Python and PowerShell function apps.
Impact
How many customers (roughly) would be impacted by this break? If not known, how can we figure it out? This may require host changes to gather metrics.
This is possible to break customer's with memory intensive Python function apps. May increase the number of out-of-memory errors (e.g. "Python exit code 137")
Compat-mode support
We'd like to enable compat-mode support for every breaking change. This may not be feasible in reality, but each proposal should include a plan to switch back to the previous behavior with a feature flag. This requirement will be evaluated on a case-by-case basis.
If the error is impacting large number of customers, changing the feature flag (e.g. PYTHON_THREADPOOL_THREAD_COUNT) to 1 should mitigate the issue.
Alternatives
Were any alternatives discussed? Is there any way to do this without a break?
This requires function host to expose host capability and let Python worker to consume. Control of this value lays in the worker logic. This feature requires collaboration with the Intelligent Language Worker Concurrency design, @alrod has more context on this.
Detection
Can we detect that a customer is using this when they upgrade from v3? Is there a specific error that can be thrown with a link to migration guidance?
Checking the FunctionsLogs table. During the worker initialize request handling, it will show that the thread count is unlimited. Correlating this information with Function Host version, can determine how many customers are using this feature.
Support
Will there be any incidents-per-day impact? Who will be the support contact? Does support need to be notified of this change? (SPOT)
As mentioned, "Python exit with 137" error count may increase. @vrdmr and @Hazhzeng are the ones to help in this scenario. Anything with thread scheduling, @alrod is the one to contact.
Documentation
Feature flag default value needs to be updated for v4 function apps.
Components impacted
What components does this change impact? Examples of areas (this list may not be exhaustive):
- Host
- Worker
Performance
Does the change have any performance impact? There may need to be some implementation complete before this can be measured.
Should increase I/O bound function app throughput. Introduce a risk or memory intensive function app.
Motivation
What is the motivation for the change?
This will increase the throughput of I/O intensive Python and PowerShell function apps.
Impact
How many customers (roughly) would be impacted by this break? If not known, how can we figure it out? This may require host changes to gather metrics.
This is possible to break customer's with memory intensive Python function apps. May increase the number of out-of-memory errors (e.g. "Python exit code 137")
Compat-mode support
We'd like to enable compat-mode support for every breaking change. This may not be feasible in reality, but each proposal should include a plan to switch back to the previous behavior with a feature flag. This requirement will be evaluated on a case-by-case basis.
If the error is impacting large number of customers, changing the feature flag (e.g. PYTHON_THREADPOOL_THREAD_COUNT) to 1 should mitigate the issue.
Alternatives
Were any alternatives discussed? Is there any way to do this without a break?
This requires function host to expose host capability and let Python worker to consume. Control of this value lays in the worker logic. This feature requires collaboration with the Intelligent Language Worker Concurrency design, @alrod has more context on this.
Detection
Can we detect that a customer is using this when they upgrade from v3? Is there a specific error that can be thrown with a link to migration guidance?
Checking the FunctionsLogs table. During the worker initialize request handling, it will show that the thread count is unlimited. Correlating this information with Function Host version, can determine how many customers are using this feature.
Support
Will there be any incidents-per-day impact? Who will be the support contact? Does support need to be notified of this change? (SPOT)
As mentioned, "Python exit with 137" error count may increase. @vrdmr and @Hazhzeng are the ones to help in this scenario. Anything with thread scheduling, @alrod is the one to contact.
Documentation
Feature flag default value needs to be updated for v4 function apps.
Components impacted
What components does this change impact? Examples of areas (this list may not be exhaustive):
- Host
- Worker
Performance
Does the change have any performance impact? There may need to be some implementation complete before this can be measured.
Should increase I/O bound function app throughput. Introduce a risk or memory intensive function app.
/cc: @AnatoliB @vrdmr @stefanushinardi
The text was updated successfully, but these errors were encountered: