I was looking into a TSVB related performance problem when I came across this - https://github.com/elastic/kibana/pull/92812/files#diff-1b2036375d883a146d1c7e25c3d366dd1cb0ce30574ef4da7ce6d222ca6f4d23 - an endpoint specific index pattern cache. It addresses this issue - #93751
It appears that index patterns are cached by id. Unfortunately ids are not unique across spaces. This is a security vulnerability.
Further, I don't see a method of cache invalidation. Am I missing it?
It looks like the field list is loaded manually, addressing concerns about field level security, although its unclear from the code why the field list is being loaded in a non standard manner.
How should this be addressed?
First I'm curious about the test - are the index pattern saved objects large? Do they have full field lists? If so, it would be good to strip out the field list and try the test again.
Its interesting that caching the index pattern instance resolves the performance concern ALTHOUGH the field list is still loaded. That means the performance concern is related to loading the saved object or instantiating the index pattern instance. The field list should be the bulk of the index pattern size.
Taking a step back - server side index pattern caching should be handled on the service level. Any team that loads index patterns on back end calls would run into this problem.
I was looking into a TSVB related performance problem when I came across this - https://github.com/elastic/kibana/pull/92812/files#diff-1b2036375d883a146d1c7e25c3d366dd1cb0ce30574ef4da7ce6d222ca6f4d23 - an endpoint specific index pattern cache. It addresses this issue - #93751
It appears that index patterns are cached by
id. Unfortunatelyids are not unique across spaces. This is a security vulnerability.Further, I don't see a method of cache invalidation. Am I missing it?
It looks like the field list is loaded manually, addressing concerns about field level security, although its unclear from the code why the field list is being loaded in a non standard manner.
How should this be addressed?
First I'm curious about the test - are the index pattern saved objects large? Do they have full field lists? If so, it would be good to strip out the field list and try the test again.
Its interesting that caching the index pattern instance resolves the performance concern ALTHOUGH the field list is still loaded. That means the performance concern is related to loading the saved object or instantiating the index pattern instance. The field list should be the bulk of the index pattern size.
Taking a step back - server side index pattern caching should be handled on the service level. Any team that loads index patterns on back end calls would run into this problem.