Hi Christian, given the recent work towards getting logs to a separate store to relieve CouchDB and to make it possible to move it into a store that's more appropriate for logging load and some other bits that are already implemented (removing the DB based polling, being able to disable log collection), I think it makes sense to be able to disable activation writing as well! In that sense, yes I do agree on going forward with the proposal + implementation.
One thing that has me worried a bit is the way we're handling global, namespaced and per-action limits today. I'm wondering if at some point we'll need to consolidate those and make them cascade reliably. For this specific knob, for example, I think it would make sense to have one at the system level and on the action/trigger level accordingly. For some of our limits that might be true today already, I feel like it might not be for all though (although I admittedly haven't double-checked). Cheers, Markus Am Di., 23. Okt. 2018 um 14:22 Uhr schrieb Christian Bickel < cbic...@apache.org>: > Hi developpers, > > in some performance tests in the past we've seen, that there are the > following issues with Cloudant/CouchDB: > - not all activations can be stored (there are error logs in the invoker, > that storing was not possible) > - during bursts, CouchDB needs to process each document to update all views > in the activations-DB. If CouchDB is not able to process them immediately, > because of a queue, calling these views returns an error or the result will > be outdated (on calling them with stale). This has the impact, that there > is a delay for all users of the system until their activation appear after > calling `activation list`. > > To not have negative impact of some high-load users on the system the > proposal is, to not store activations in activations-store for some > specified namespaces. > My proposal of an implementation is to put this flag into the > limits-document in subjects database. > This means, it can only be set by the administrator with wskadmin. > > I already opened a PR with this proposal: > https://github.com/apache/incubator-openwhisk/pull/4078 > > Do you agree on going forward with this proposal and implementation? > > Thanks a lot in advance for your feedback. > > Greetings > Christian >