Новости 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 Ответов
  • 1867 Просмотров
*

..С...е...р...ы...й..

  • Захожу иногда
  • 51
  • 110 / 2
Посмотрел все имеющиеся доки и видео по этому компоненту, но узнал не более 5% о нем.
Приложение функционально-мощное, но разработчики как то не позаботились о простоте понимания. Конечно им разработчикам, когда они знают каждую кнопочку, легко оперировать функционалом своего изобретения и этот их необъективный взгляд не позволяет им видеть на сколько сложно их приложение для человека только открывшего его для себя. Лично моё ощущение, когда я открываю админку этого компонента - хочется бахнуть рюмку другую чего то крепкого, что бы избавиться от горького чувства отчаяния и расслабить перенапряжение в мозге.

Сейчас пытаюсь разобраться в профилях, для профилей существуют три заготовки - три типа с разными наборами полей. Один из них ("User") назначен по умолчанию. "User Mini" не понятно чем отличается от "User", "User Profile" уже содержит много информации даже ненужной, Аватар, Национальность и т.д.
Если я выбрал "User Profile" в качестве типа по умолчанию, можно ли, что бы при регистрации нужно было заполнить всего 3-5 полей, а уже при редактировании профиля отображались все 10-20 полей?

И еще, в конфигурации компонента, на вкладке "Сайт (фронт-энд)" есть опции:
  Сайт :: По умолчанию регистрации пользователей
    Тип контента:

  Сайт :: По умолчанию содержимое пользователей
    Тип контента:

Первый задает тип, который используется при регистрации, а второй как я понял задает тип для редактирования своего профиля.
Но если для первого я указал тип "User Mini", а для второго "User Profile" то в редактировании всё равно выводиться "User Mini".
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться