TYPO3 - Падение производительности при доступе к записи с большим количеством записей (> 1 млн)

Я разработал расширение extbase со списком и подробным представлением (список и действие показа). Чтобы ссылки выглядели красиво, я использую realurl...

<f:link.action action="show" pageUid="43" arguments="{record:record.uid}">{record.name}</f:link.action>

domain/?tx_abc_abc[record]=1&tx_abc_abc[action]=show&tx_abc_abc[controller]=Abc&cHash=10c78febea3ae5dsdf535fb36ca6d08

domain/category/record_id/

Но теперь, когда количество записей превышает 1 миллион, я испытываю небольшое падение производительности при доступе к странице сведений. У меня тоже 2 языка.

Что я могу сделать, чтобы остановить падение производительности или повысить производительность?

В некоторых настройках я вижу, что доступ к записи реализован так:

domain/category/?record_id=DE00ABC03709

Это делается с помощью JSON View/(RESTful) API? https://usetypo3.com/json-view.html


typo3 typo3-extensions typo3-8.x
person Philipp M    schedule 29.12.2017    source источник
comment
Может быть много факторов, вы можете проверить record свойства вашей модели, сколько из них имеют \TYPO3\CMS\Extbase\Persistence\ObjectStorage? а также проверьте кэширование страницы сведений и конфигурации вашего сервера.   -  person Ravi Sachaniya    schedule 29.12.2017
comment
Используете ли вы метод findAll() репозитория вашего домена для отображения всех объектов в представлении списка? В этом случае вы можете рассмотреть возможность использования разбивки на страницы, чтобы уменьшить объем данных, извлекаемых из базы данных и отображаемых в виде HTML. Лучшей альтернативой было бы действительно уменьшить накладные расходы HTML, используемые для переноса каждого объекта, и получать данные только через AJAX как JSON - рендеринг может выполняться с привязкой данных, например, например. Угловой или например. RivetJS, который является облегченной реализацией только для этой цели.   -  person Oliver Hader    schedule 03.01.2018

Ответы (1)


arrow_upward
0
arrow_downward

Всегда ли происходит падение производительности? или это зависит от кеша? достаточно ли велик ваш кеш, чтобы кешировать все страницы с подробностями?

Проведите тест кеша:

  1. очистить кэш,
  2. запрашивать все страницы деталей с увеличением ID (поскольку эти запросы не кешируются, все страницы должны быть на одной скорости, полная отрисовка с заполнением кеша),
  3. затем запрашивайте страницы с подробностями с уменьшающимся идентификатором (теперь все страницы должны показывать более быстрый ответ, так как должна возвращаться только кешированная страница). Если ваш кеш слишком мал для некоторого идентификатора, все последующие запросы должны показывать более медленный ответ, чем 2.

В целом:
Для больших данных (более) важно иметь индексный ключ в поле, в котором вы выбираете записи.
Меня интересует ваш шестнадцатеричный идентификатор в вашем примере, поскольку TYPO3 обычно использует только десятичные целые числа. (поле uid, которое обычно является индексным ключом).

В любом случае вы можете использовать другие поля для выбора, особенно как часть URL-адреса (например, поле заголовка для новостей). Тогда дополнительный индексный ключ может быть полезен для больших данных.

person Bernd Wilke πφ    schedule 29.12.2017