Новости Joomla

Человек на GitHub ускорил Joomla в 600 раз на объёме 150к+ материалов в 1700+ категориях

Человек на GitHub ускорил Joomla в 600 раз на объёме 150к+ материалов в 1700+ категориях

👩‍💻 Человек на GitHub ускорил Joomla в 600 раз на объёме 150к+ материалов в 1700+ категориях. На старте его сайт на Joomla 3 вообще не смог обновиться на Joomla 5. Пришлось делать экспорт/импорт материалов. Проделав всё это он запустил-таки этот объём данных на Joomla 5. Тестовый скрипт грузил 200 материалов из этого объёма всего за 94 секунды ))) А главная страница с категориями грузилась 20 секунд. Добавив индекс для таблицы #__content

CREATE INDEX idx_catid_state ON #__content (catid, state);
он сократил время загрузки категорий до 1 секунды. Затем наш герой решил поковырять SQL-запрос в ArticleModel, который отвечает за выборку материалов. И решил заменить тип JOIN на STRAIGHT_JOIN для категорий.
// ->from($db->quoteName('#__content', 'a'))->from(    $db->quoteName('#__content', 'a')    . ' STRAIGHT_JOIN ' . $db->quoteName('#__categories', 'c')    . ' ON ' . $db->quoteName('c.id') . ' = ' . $db->quoteName('a.catid'))// ->join('LEFT', $db->quoteName('#__categories', 'c'), $db->quoteName('c.id') . ' = ' . $db->quoteName('a.catid'))
Что сократило загрузку 200 материалов из 150к с 94 секунд до 5. К слову сказать, боевой сайт на Joomla 3 крутится на 12CPU 64GB рамы. А все манипуляции с кодом он делает на базовом 1CPU 1GB сервере и замеры скорости даны именно для базового сервера. Но это всё в дискуссии, хотя в идеале должно вылиться в Pull Requests. Мы - Open Source сообщество, где никто никому ничего не должен. Джунгли. Но человек ищет пути оптимизации Joomla и предлагает решения. Если оказать поддержку и предложить помощь хотя бы с тестированием самых разнообразных сценариев, то возможно эти улучшения смогут войти в ядро. Пусть не быстро, пусть через несколько лет, пусть не все, но войдут. Достаточно предложить руку помощи и приложить немного усилий.
Дискуссию на GitHub можно почитать здесь.@joomlafeed#joomla #community #php

0 Пользователей и 1 Гость просматривают эту тему.
  • 0 Ответов
  • 119947 Просмотров
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Данная ошибка проявляется если скрипт выполняется больше, чем ему разрешено в конфигурации PHP. Например вы устанавливаете какой-то довольно большой компонент или производите импорт данных. В конфигурации PHP по умолчанию максимальное время выполнения для скриптов задается в районе 20-30 секунд. На разных хостингах это значение может отличаться.

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


Если у вас возникает такая проблема, то можно сделать следующее:

1. Попробовать самостоятельно изменить это значение, добавив в самое начала index.php (рассположенного в корне сайта) следующие строчки:

<?php ini_set("max_execution_time""60"); ?>

или

<?php set_time_limit (60); ?>

или же положив в корень сайта файл .htaccess следующего содержания:

Код
	php_value max_execution_time 60

Если же такой файл уже есть в корне сайта — просто добавьте в него приведенную выше строку.

2. Если это не помогло — обратитесь к администратору хостинга и попросите увеличить время выполнения PHP-скриптов, допустим до 1 минуты.
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Как избавиться от ошибки: Call-time pass-by-reference has been deprecated

Автор smart

Ответов: 0
Просмотров: 70554
Последний ответ 07.05.2007, 17:56:25
от smart
Как убрать ошибку «OverLIB 4.10 or later is required for the HideForm Plugin»?

Автор smart

Ответов: 0
Просмотров: 24260
Последний ответ 14.03.2007, 17:22:07
от smart