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
When running wadm in production at cosmonic, we discovered that wadm uses a ton of bandwidth querying data from the store. Back of napkin math put us around 500GB/month just for querying linkdefs and wadm state data. I will document a more elegant solution in another issue, but we should probably just do a single "snapshot" lookup of state (wadm_state + linkdefs + claims) that is then used by all scalers handling a given event. This means that rather than each scaler querying individually, it will just be queried once.
The text was updated successfully, but these errors were encountered:
This works by looking up all the data once per event (whenever scalers
are called). This reduces lookups of links by at least 40% and should
reduce data usage as well (though not as much as doing some sort of
caching would)
FixeswasmCloud#203
Signed-off-by: Taylor Thomas <[email protected]>
)
This works by looking up all the data once per event (whenever scalers
are called). This reduces lookups of links by at least 40% and should
reduce data usage as well (though not as much as doing some sort of
caching would)
Fixes#203
Signed-off-by: Taylor Thomas <[email protected]>
When running wadm in production at cosmonic, we discovered that wadm uses a ton of bandwidth querying data from the store. Back of napkin math put us around 500GB/month just for querying linkdefs and wadm state data. I will document a more elegant solution in another issue, but we should probably just do a single "snapshot" lookup of state (wadm_state + linkdefs + claims) that is then used by all scalers handling a given event. This means that rather than each scaler querying individually, it will just be queried once.
The text was updated successfully, but these errors were encountered: