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
We're currently deploying Symbolicator for 3 different enviroments (production, canary, LPQ) and 3 different platforms (native, JS, JVM). Since all combinations are possible, that results in 9 different deploys (with varying numbers of pods each). Ideally we would boil that down to just 2 (production and canary), i.e. no more LPQ and no more different platforms.
Some background: The LPQ machinery exists so we can move events that take a long time to process to a different queue so they don't block other more "well-behaved" events from being processed. It's effectiveness at this task is questionable, especially considering the massive complication it causes on the Sentry side. The problem may be better tackled by autoscaling.
The deployments for different platforms exist because the platforms get different amounts of load (JS the most, then native, then JVM) and also because when we were implementing the non-native platforms it was convenient to have separate instances that wouldn't take all symbolication down when we were tinkering with something. This might also be a matter of autoscaling.
The text was updated successfully, but these errors were encountered:
We're currently deploying Symbolicator for 3 different enviroments (production, canary, LPQ) and 3 different platforms (native, JS, JVM). Since all combinations are possible, that results in 9 different deploys (with varying numbers of pods each). Ideally we would boil that down to just 2 (production and canary), i.e. no more LPQ and no more different platforms.
Some background: The LPQ machinery exists so we can move events that take a long time to process to a different queue so they don't block other more "well-behaved" events from being processed. It's effectiveness at this task is questionable, especially considering the massive complication it causes on the Sentry side. The problem may be better tackled by autoscaling.
The deployments for different platforms exist because the platforms get different amounts of load (JS the most, then native, then JVM) and also because when we were implementing the non-native platforms it was convenient to have separate instances that wouldn't take all symbolication down when we were tinkering with something. This might also be a matter of autoscaling.
The text was updated successfully, but these errors were encountered: