If you want to create a test account for me, I can try the live version.
Potentially relevant to include for both front-end and back-end performance results is which type of user you’re logged in, as each may take different code paths.
For the front-end, whether you are cleaning the cache or not for each attempt is relevant as well.
The FCP and LCP times seem quite poor to me.
It looks like a significant amount of time is on the server too, even for SN 1.1.
Without access to server metrics, that one may be hard to diagnose. I can run it locally, but, at minimum, the resource allocation (vCPUs, memory, # of instances) would be good to know to compare to. If you want to give me read-only access to any observability systems, I can check the live server more closely.
Otherwise, Ven @Jhanarato and I can still profile the server locally to find bottlenecks. If @HongDa is not too familiar with profiling and observability, I’m sure we could demonstrate a bit too.
From a purely speculative standpoint, I’d guess that server time is either spent mostly:
- in Elasticsearch
- for which more indices, more resources, and/or a cache might help
- in the Python, iterating or otherwise parsing & transforming the data
- for which more efficient memory usage and reducing transforms and iteration might help (or, ofc, more resources)
- I often find that (de-)serialization & allocations, especially in languages where they aren’t so explicit, end up being bottlenecks, particularly with large datasets.
On the front-end, it’s usually:
- number of requests
- optimize with parallelization, consolidation, caching, and/or lazy loading where possible
- number of (re-)renders
- optimize with reducing the number of prop and state changes
Can look at a flame graph of either for a quick analysis. On the front end, you can record one in the Performance tab of Chrome DevTools (or similar).
If there’s any structural latency inherent in the architecture/data flow, that’s a separate story to analyze. For something larger like that, I’d start with the original goals of the Bilara v2 project first, in order to figure out what to optimize. (I don’t know the history and haven’t stumbled upon a clear ADR myself yet)
There’s at least two reports in the translator alpha thread of performance issues when compared to v1, so those are use cases I’d suggest starting with. Knowing the resource allocation of v1 would also be helpful for comparison.