Hi Markus, thanks a lot for your response.
I definitely agree, that all limits should be reviewed and reworked. The reason why I've chosen this limit as per-namespace-limit and not as per-action-limit is, to give the operator of Openwhisk the ability to protect the own database. If the limit would be implemented on a per-action basis, the user could always change it back and flood the database during very high load intervals. but adding this as per-action-limit, like ningyougan proposed in the PR, makes definetly sense. But I would see it as separate PR. Greetings Christian Am Di., 23. Okt. 2018 um 16:23 Uhr schrieb Markus Thömmes < [email protected]>: > 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 < > [email protected]>: > > > 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 > > >
