hi Chetan, thanks for discussing this with me on github and slack. For the benefit of others, the latter was about computing the size when needed vs storing it when it's available. Chetan's point was that to compute this on demand via json serialization or really any other method will either have an impact in both space (gc) and time. The value is readily available when the activation is completed and nested inside the activation response.
Hence, I support this change given that it has utility for increasing platform visibility and telemetry as implemented in the path. -r On Thu, Oct 3, 2019 at 5:44 AM Chetan Mehrotra <[email protected]> wrote: > Hi Team, > > I would like to capture the activation response size as part of user event > data. This would allow us to understand the distribution of response size > across various invocations. This would be useful input for the Activation > Persister Service work (#4632) > > For this purpose a PR is opened (#4660) which captures the HTTP response > string size and makes it part of `ActivationResponse` -> `WhiskActivation` > -> `Activation` flow > > The size could have been computed at `Activation` level only but that would > have added the overhead of serializing the response json object to json > string. In current used approach the size is pre known when we construct > the ActivationResponse > > Currently with this change a new numeric `size` attribute would get added > to the `WhiskActivation` json representation which gets stored in db. > Technically we can avoid making it part of persisted json as this value is > only needed while constructing the `Activation` instance from in memory > `WhiskActivation` instance > > Questions > > 1. Is current approach fine > 2. Should we avoid persisting the size attribute > 3. Or would it be ok to get size by converting the response to json string > while constructing Activation instance in UserEvent flow > > Chetan Mehrotra > [1] https://github.com/apache/openwhisk/pull/4632 > [2] https://github.com/apache/openwhisk/pull/4660 >
