contact_detail apdex: Research problem and develop plan

[michaelkohn]

Research problematic area and develop a plan for resolving

[latin-panda]

Yesterday, I dived into load_descendants and load_targets but found nothing we could do. Today, I had better luck! I found out that load_reports (code) is requesting the reports' docs twice, the tech explanation is:

• We use the search feature to return the reports (and docs) from the selected contact and its descendants (code)
  • The search feature uses the data record service (code) to get the docs. Makes a request to the user's local db
• Then we take the ids from the search result and build the data for the report's header (code)
• To build that header, we are retrieving the reports' docs again by using the data record service that also request the user's local db (but somewhere else in the code)

Instead of retrieving the same information twice, reports' docs, we can find a way to pass that information to the process that generates the reports' headers and void querying the user's local DB twice. And make sure we are not breaking anything else using the same processes.

[latin-panda]

I checked load_contact_data, load_contact_summary and load_tasks but found nothing significant in webapp.

In another iteration, I can check the rules engine and the rendering after the data is fetched, but this last one isn't considered in the Apdex score.

Other ideas for tiny improvements:

• Pass the selected contact ID and the descendants' IDs to the services that get reports and tasks to avoid going through the list of data twice.
• Add all the tasks' emissions fields in the rule engine to avoid going through the list of data twice. Tasks list adds: date, overdue and owner. While contact detail adds overdue, the calculation is the same.

[michaelkohn]

I'm closing this issue since it was marked as "Done" already.

[latin-panda]

These are developed here.