info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- iionly@iionly
iionly - 0 likes
- Reuven@reuven
Reuven - 0 likes
- iionly@iionly
iionly - 0 likes
- Reuven@reuven
Reuven - 0 likes
You must log in to post replies.Make use of Elgg's caching mechanisms + PHP opcode caching + memcache. The latter helps with caching DB queries. It does help with recurring queries. But don't expect wonders as it probably can't help with complicated queries or if someone calls page 10403 of a list that no one has recently called and is therefore not cached.
Thank you iionly.
I'll check the use of cache.
However, in this specific case the underlying data can change many times per second (depending on the number of users). Therefore, the standard approach of paging may not work here. In addition, the queries depend on many variables, including free text search. That is, there are virtually endless possibilities. Therefore, Therefore, I think the use of cache will actually be impossible.
On this page there is a suggestion for a solution based on update time ... interesting.
I can't really help you with the decision here as I have no idea what kind of data you want to display.
If this data is changing so frequently, does it even make sense to display it? Does it make sense to display all of it or wouid it enough to display the "latest" X entries - as they are "latest" at the time of request.
Thank you iionly, you are right.
We display the latest (i.e. sort DESC), log the time of the last one and the next page will start from that time downward. Of course, we miss those records that was changed in between, but we do not have records that may appear twice or more.