You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2019/11/15 16:37:37 UTC

[GitHub] [openwhisk] tysonnorris commented on issue #4725: Reactive prewarm pool

tysonnorris commented on issue #4725: Reactive prewarm pool
URL: https://github.com/apache/openwhisk/issues/4725#issuecomment-554433907
 
 
   Yes agree this is similar idea. The differences I would say are:
   - currently there is no "admin API" at controller, which exposes operator-specific APIs that adjust configs after deployment - I think this type of API is required for exposing these controls externally; for now I would avoid this by keeping logic internal to invoker
   - while adding more sophisticated prediction approach would be great, reactive approach specifically does not make guesses at all, it explicitly only reacts to data in the past, more similar to a health check - you would (typically) not attempt to predict whether a health check will fail, but you do want precise behavior when a series of health check failures occur. With prewarms, this would simply trigger loading of additional prewarms, once some "prewarm misses" have occurred. And when allowing loading of additional prewarms, we also need to allow some form of "prewarm idle timeout", since we also don't want to end up with prewarms occupying excess resources, if they are not getting used.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services