Response time
# avo-2
m
Hey guys. What is the browser response time for an #index action, paginated with 24 records, without relationships and using PostgreSQL, disregarding a cold start?
l
Hi @microscopic-dream-82397 I think there isn't a fixed value, it depends on many factors like the browser, server's configuration and capacity etc...
m
Using Beeline's Honeycomb APM tool I identified that most of the time to respond occurs in the processing of "action_view render_layout" with "action_view render_template" inside. It seems to be a disproportionate amount of time, much longer than other parts of the code take to execute. I don't know if it would be possible to cache or improve performance for a system with different user profiles that display or hide attributes according to permissions

https://cdn.discordapp.com/attachments/1148711116340461598/1148896695501979688/SAVE_20230906_052504.jpg

l
can you reproduce that locally with something like
rack-mini-profiler
?
we'd love to have a look, but nothing compute-heavy comes to mind there
not saying there isn't, but if there is something on our end it should be easy to pinpoint and reproduce
m
With rack mini

https://cdn.discordapp.com/attachments/1148711116340461598/1148991166289809458/image.png

l
can you create a reproduction repository with rack mini so we can investigate locally?
m
Added to SIA private repository. The instructions are in the README, but in Portuguese
l
Let me know if translation is required 🙂
l
can you please invite Paul too? he'll have the first look 😛
m
already added
l
Obrigado 🙂
m
De nada
admin@teste.com / admin123
users in /db/seeds/0040_usuarios.rb
Good morning guys. After some attempts to find the cause of the delay with slower requests
Using different tools like stackprof, rbspy rack-mini-profiler, Jaeger APM
They all indicated that the delay is related to the process of rendering index.html.erb and using application.html.erb
But I believe there is nothing you can do as a user, it would have to be an optimization process by someone who understands AVO deeply
I read some articles about caching and partials, but these changes can bring benefits as well as unwanted side effects
It's not a very long response time, but I believe it can be optimized, perhaps using threads/fibers, or code refactoring with more optimized methods
I created a gist with the survey, but unfortunately I don't know enough about Ruby on Rails to help
l
Hi @microscopic-dream-82397 we appreciate your investigation efforts here! We're focusing on avo3 release right now. Will get some time after november. I believe we should focus on improving performance without caching at first... Caching, as you mentioned can bring some unwanted side effects, like outdated data, which would be far from ideal. However there can be sections on our code where caching would not bring that side effect, we should carefully analyze them. Again, great investigation and thank you a lot for the report. We will give it more thorough attention when we have the available time.
m
Thank you, Paulo. AVO is getting better and better and version 3 brought many improvements and features. Congratulations to the team!