[TYPO3-mvc] filter and pagination views of own extension really slow

[Nicole Cordes]

Hi Daniel,

maybe these steps will help to improve your situation:

- check database indexes to speed up query time
- do you need all information of an event in the list or may you consider to
set some properties to @lazy to not load them on object initialization

The pagination wizard itself just sets the limit to the query and as long as
you use "normal" queryResultObjects the request is just send once to the
database. Maybe you can provide some code to look over to be sure none of
you actions already fetches whole objects.


Best regards,
Nicole

--
Nicole Cordes
TYPO3 CMS Active Contributor

TYPO3 .... inspiring people to share!
Get involved: typo3.org

-----Ursprüngliche Nachricht-----
Von: typo3-project-typo3v4mvc-bounces at lists.typo3.org
[mailto:typo3-project-typo3v4mvc-bounces at lists.typo3.org] Im Auftrag von
Daniel Hirth
Gesendet: Mittwoch, 2. April 2014 10:44
An: typo3-project-typo3v4mvc at lists.typo3.org
Betreff: [TYPO3-mvc] filter and pagination views of own extension really
slow

Hi guys, 

we are having performance issues with an extbase extension, so i was not
sure in which forum to post this thread, but since this seems to me like a
rather extbase-specific problem i chose this forum. If this was the wrong
choice, please feel free to move this thread. 

Our setup is this: 

We wrote an extbase extension to (in short) display events. The event-model
can contain instances of other models, e.g. location or gallery (with
multiple instances of an image-model per gallery) . 

Currently, there are around ~3700 event-items stored and available in the
backend. The TYPO3 version used is 6.1.7.

In the event list view in the frontend, the user can filter events by date
(from ... till) and by location: 

<f:form object="{filter}" name="filter" method="post" action="list"
noCache="1"> ..
</f:form>

The filter object is used in the repository class to add constraints to the
repository query. The resulting events are paginated with the paginate
object. 

<f:widget.paginate objects="{events}" as="pageevents"
configuration="{itemsPerPage:settings.itemsPerPage, insertAbove:1,
insertBelow:1, maximumNumberOfLinks:settings.pagerMaxLinks}">
    <f:for each="{pageevents}" as="event">
        <f:render partial="Event/EventItem" arguments="{event:event}" />
    </f:for>
</f:widget.paginate>

The list-action itself is registered as cacheable while the filter-form has
noCache="1" as argument, because otherwise changes of the filter form by the
user won't work becaus of the cache. 


The problem is as follows: 

The loading of the default event list (first page of the pagination and
empty filter) itself is pleasantly short. BUT switching to a different page
of the event list or changing and submitting the filter form takes
incredibly long to load, between 10 seconds and 30 seconds, roundabout. I
wondered if all events where fetched from the db BEFORE the pagination
widget limits the output, but the widget description says: "However, the
blogs are NOT fetched from the database until you actually use them, so the
paginate ViewHelper will adjust the query sent to the database and receive
only the small subset of objects." Also, the loading time is equally as long
if a filter is chosen that returns only, like, 3 results. 

Does anyone know how we can make these actions load faster? What are we
doing wrong? 

I would be grateful for any idea. 

Thanks a lot. 
_______________________________________________
TYPO3-project-typo3v4mvc mailing list
TYPO3-project-typo3v4mvc at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc