Looks like last stage when we pick up campaigns from the cache the complexity is O(N LogN) , for every matched campaign id N we use LogN complexity lookup in the last cached table ~ O(N LogN) .
Matching 20-30 campaign per request is within our benchmark goals however going above this number degrades performance.
- Use relational cache entries to solve the issue , we should avoid last stage campaign lookup , rather have pointers saved in the preceding matcher cache and use those pointers to retrieve campaigns directly instead of performing O(LogN) lookup.
Looks like last stage when we pick up campaigns from the cache the complexity is O(N LogN) , for every matched campaign id N we use LogN complexity lookup in the last cached table ~ O(N LogN) .
Matching 20-30 campaign per request is within our benchmark goals however going above this number degrades performance.