I was wondering how one would go about optimizing _BuildItemMap found in
Tickets_Overlay.pm.
One thing that it does on an unrealistic test database that has 10,000
results for a search query is that it loads each row into memory and sorts
them. Then _BuildItemMap only keeps the ticket id’s. This isn’t bad, but
for 10,000 tickets, with about 4k/row, that’s 40MB of information that
needs to be transferred from the database.
Can _BuildItemMap be written such that it doesn’t use ItemsArrayRef and
uses a custom SQL query that pulls down only the ticket ids, instead?
– Gene
I was wondering how one would go about optimizing _BuildItemMap found in
Tickets_Overlay.pm.
One thing that it does on an unrealistic test database that has 10,000
results for a search query is that it loads each row into memory and sorts
them. Then _BuildItemMap only keeps the ticket id’s. This isn’t bad, but
for 10,000 tickets, with about 4k/row, that’s 40MB of information that
needs to be transferred from the database.
What’s your realistic test case?
I was wondering how one would go about optimizing _BuildItemMap found in
Tickets_Overlay.pm.
One thing that it does on an unrealistic test database that has 10,000
results for a search query is that it loads each row into memory and sorts
them. Then _BuildItemMap only keeps the ticket id’s. This isn’t bad, but
for 10,000 tickets, with about 4k/row, that’s 40MB of information that
needs to be transferred from the database.
What’s your realistic test case?
Probably on the order of 1000 tickets. That’s only 4MB, but that still
takes time.
Can _BuildItemMap be written such that it doesn’t use ItemsArrayRef and
uses a custom SQL query that pulls down only the ticket ids, instead?
– Gene
– Gene
What’s your realistic test case?
Probably on the order of 1000 tickets. That’s only 4MB, but that still
takes time.
In most cases, your ticket searches are going to be limited to pages,
usually of 25,50 or 100 items. What’s the use case you’re running into
this being any sort of an issue?
What’s your realistic test case?
Probably on the order of 1000 tickets. That’s only 4MB, but that still
takes time.
In most cases, your ticket searches are going to be limited to pages,
usually of 25,50 or 100 items. What’s the use case you’re running into
this being any sort of an issue?
The order 1000 is a typical max case (hopefully).
Here’s a use case:
On an fairly active queue,
Select all (new|open|stalled) cases. say 1000 tickets
The search results are paginated (no problem here).
Choose a ticket in the search results.
/Ticket/Elements/Tabs is called
my $item_map = $session{‘tickets’}->ItemMap;
RT:
:ItemMap calls _BuildItemMap
RT::_BuildItemMap calls ItemsArrayRef
1000 Tickets get read
1000 Tickets get sorted
_BuildItemMap constructs next/prev links from ItemsArrayRef
…
Serialize first/prev/next/last information in session data
Construct First/Pref/Next/Last links in tabs.
It would be nice if instead of calling ItemsArrayRef and reading all the
ticket data if something else gets called to only load the ids. I hope
this example is a lot clearer than my initial request. On subsequent
displays of tickets in the search, there is no problem since all of the
next/prev information is in the session data.
– Gene