◄ ► | Muuda | Home | Admin | en de fr et | Sign in

#6167 (Should we cache delayed values?)

40 · by Luc Saffre · in Developers · assigned to Sharif Mehedi

Kokkuvõte

The detail of a school.Groups in Lino Prima takes a tangible amount of time on our production site. How can we optimize this?


Answer: using the delayedhtmlbox decorator.


We tried by making the HTML display mode to be always delayed (see DELAYED_HTML in lino.core.elems) and

it worked as such, but it caused --or revealed-- some strange test failures. The root cause of the evil seems to be the fact that LightWeightContainer creates a new virtualfield when it is actually too late for creating new data elements.... The true solution might be that Actor.get_data_elem(), when it detects a slave actor, should not return that actor's class object but wrap it into the htmlbox that is currently created in LightWeightContainer. But this is a bigger story, right now the delayedhtmlbox decorator is fine.

Children

Kommentaarid

  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) (1 reply) : I will release this now to the prima prod sites (pdg and primademo on pilv) .
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : I reverted my lino repo to before @8lurry's and started the test suite. If these problems really came by this relatively small change, I'll revert it and try to implement these heavy views in Prima using an explicit delayedhtmlpanel. And if that works, we leave the circular data/layout element creation iss...
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : I discovered that we have a decorator "delayedhtmlbox", which creates a field DelayedHtmlBox. I could have used this instead of asking to make the html display mode delayed.
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : Idea: the true solution might be that Actor.get_data_elem(), when it detects a slave actor, should not return that actor's class object but wrap it into the htmlbox that is currently created in LightWeightContainer.
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : After a day of poking around I can tell you that this is a tough one...
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : The When Lino starts up page does not mention layout elements right now. But it should.
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : The fundamental problem is that LightWeightContainer.__init__() creates a VirtualField, which it adds to the lh.layout._datasource. That's kind of forbidden in Lino. All data elements (database fields, virtual fields, actors, actions...) are assumed to exist when the kernel starts creating layout el...
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : The problem is visible e.g. with "python manage.py test tests.test_notify" in noi1r.
  • 1 aasta, 3 kuud ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : I published my changes on lino and react.
  • 1 aasta, 3 kuud ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : Through the getmro, the get_data_elem were returning a VirtualField and create_atomizer was creating a StoreField for it. But now that we removed the getmro stuff, data element for slave panels are now subclasses of actors.Actor. And create_atomizer stops here.
  • 1 aasta, 3 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : Together we removed the "for cls in getmro(self):" in Actor.get_data_elem(), which fixed the issue in lets1.rst but caused #5739 (Oops, get_atomizer(...) returned None) to reappear...
  • 1 aasta, 4 kuud ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : @luc I have some broken test cases that I should show you.
  • 1 aasta, 4 kuud ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : Now all the slave actors with DISPLAY_MODE_HTML are delayed.
  • 1 aasta, 4 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : Yes, the PupilsAndProjectsByGroup slave panel is not using delayed values, I guess that's because it is in summary view. So we probably don't need no caching, we just need to make slave panels use delayed_value also when it's in summary mode. @8lurry is that a quick win?
  • 1 aasta, 4 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : I increased the priority because they will complain about slowness if we don't find a solution.
  • 1 aasta, 4 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : Maybe the projects/PupilsAndProjectsByGroup slave table in the school.MyGroup detail is not a delayed value? Because it is in html or summary view.
  • 1 aasta, 4 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : My spontaneous idea is that Lino could simply cache the result of a delayed_value per user_type. But experience shows that caching is never simple. The app developer needs a way to invalidate the cache. And the ⎚ button should also clean the cache on the server-side.
  • 1 aasta, 4 kuud ago by Luc Saffre about #6167 (Should we cache delayed values?) : Created new Ticket #6167 (Should we cache delayed values?).