Poor performance with large number of entries

[animaux]

I have serious performance problems with large numbers of entries in a section. One site has about 5000 entries and getting really slow with the extension enabled.

Is entry nav fetching the entire list of entries to get the next/previous ids?

[vlad-ghita]

Yeah, it's getting all entries ... I'm thinking for a solution.

[vlad-ghita]

Well, sadly it is beyond my SQL knowledge. I read some solutions out there but can't fit them with Symphony.

I'll let this issue open, perhaps there's someone else with better understanding about the thing.

[andrewminton]

@animaux Do you mind trying out my fork to see if the prepared SQL queries help here? https://github.com/andrewminton/entry_nav/tree/integration It doesn't take Sorting Field into account yet, as it's going straight to the entries table and looking ahead/behind the entry id to get it's next/prev entries for now.

[animaux]

@vlad-ghita many thanks for looking into this!

@andrewminton thanks for this mod. Seems to do the trick fine in this case. It even leaves out the button for next/prev on the last/first entries of a section rather than looping through. EDIT: it actually messes up a bit at that point, no big deal though :)

Maybe this fork should become a seperate extension of it’s own e. g. entry nav by id?

[vlad-ghita]

Maybe this fork should become a seperate extension of it’s own e. g. entry nav by id?

For consistency, I recommend implementing the correct sort order. Otherwise, content editors will be puzzled by different prev / next entries other than the ones from main listing.

This morning, I had an idea. Will have a look this evening to see if I can implement it.

[animaux]

@vlad-ghita sounds like good plan to go! No hurries though :)

[andrewminton]

@vlad-ghita I agree. Was looking at the limit and offset options in the
EntryManager to see if there was a way to look ahead and behind based on
current ID somehow. This was a short solution for now as I had the same
issue.

On 20 May 2014 08:06, animaux notifications@github.com wrote:

@vlad-ghita https://github.com/vlad-ghita sounds like good plan to go!
No hurries though :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-43592708
.

[andrewminton]

Would caching the $entries array help in this instance? We could cache the returned result for future use maybe? therefore removing a bit of the load. I see no way to look ahead and behind the current entry ID without pulling the whole section results first at the moment.

[vlad-ghita]

Would caching the $entries array help in this instance?

Not really because you would then need to bust the cache on entry Create and Delete => another headache.

There is need of custom SQL taken from EntryManger::fetch(). 2 queries, 2 IDs. That's all.

[animaux]

@vlad-ghita @andrewminton any news on this? :)

[vlad-ghita]

Nope. And I gave up searching for a solution.

[animaux]

:{ I have to tackle a similar problem in the frontend. Will let you know if I succeed :)

[animaux]

@andrewminton just revisited this old problem which is still a problem of mine ;). Did you by any chance had a go at this in recent years?