Lighthouse (and other) speeeeeed testing for new Bilara

Working w/ @HongDa on improving page load times for new Bilara. Not sure how we can use most web page speed tests, as you need to be logged in to use Bilara. But we can use Chrome’s Lighthouse.

Feel free to post your own results if you like!

first run: brutalize w/ DN 16

Lighthouse doesn’t complete.

ok, be gentle: SN 1.1

desktop

mobile

a bit more: MN 2

desktop

mobile

4 Likes

Best wishes for this work! I’m often on the negligent side when it comes to page speed. But for translators working directly in the web app it’s going to be essential for things to be snappy.

4 Likes

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.

5 Likes

Thanks, that would be awesome. Of course it’s all unoptimized, we’ve been focusing on building things, so I guess there’ll be plenty of room for improvement.

It should be quite possible to run locally, in fact I was doing so myself, but I got out of the habit as we moved to the web. Let me see if I can get it going …

And no, there’s some errors. You can try for yourself, but yeah, it’s a bit of a moving target when under development.

Maybe wait till Hongda gets back from holidays in a week?

4 Likes

6 posts were merged into an existing topic: SuttaCentral: bug reports