УМЕНЬШЕНИЕ НАГРУЗКИ. Требует проверки!!!

[userxp]

Сегодня запостили на форуме.
Original version (>>>ссылка<<<):

Hi, all!

Recently I've rewritten a pretty large site on Joomla (it has about 200 online users all the time, as Joomla backend stats shows, >17000 content items etc.) and noticed that the page generation time started to grow ftom 0.101 secs to 0.5 after the first day, 0.7 - 1 next day...). Not very good, right? First of all I went to the MySQL console at the time of high loads and... voila - there is a `opensef_sef` MySQL query present almost constantly.

Guys, if somebody can explain me why do you fetch into the memory almost all records in sef.php [Line #173]:

if ($sefSite->id == null) $sefSite->id = -1;
  $query = "SELECT * FROM #__opensef_sef WHERE published = '1'" .
      "\nAND valid = '1'" .
      "\nAND (direction IS NULL OR direction = '' OR direction = 'o')" .
        "\nAND (site_id IS NULL " .
        ($sefSite->id ? ' OR site_id = ' . $sefSite->id : '') . ')' .
        "\nORDER BY site_id DESC, published DESC, valid DESC, LENGTH(direction) DESC";
    $database->setQuery( $query );
    if ($database->loadResult()) {
    $opensef_aliases = $database->loadObjectList();
  }  

A quick fix is to replace the query with this one:

if ($sefSite->id == null) $sefSite->id = -1;
  $query = "SELECT * FROM #__opensef_sef WHERE published = '1'" .
      "\nAND valid = '1'" .
      "\nAND (direction IS NULL OR direction = '' OR direction = 'o')" .
        "\nAND (site_id IS NULL " .
        ($sefSite->id ? ' OR site_id = ' . $sefSite->id : '') . ')' .
        "\nAND (external='{$_SERVER['REQUEST_URI']}'" .
        "\nORDER BY site_id DESC, published DESC, valid DESC, LENGTH(direction) DESC";
    $database->setQuery( $query );
    if ($database->loadResult()) {
    $opensef_aliases = $database->loadObjectList();
  }  

Hurray! It works as a charm. Page generation time is now 0.07 seconds.
Hope this will help somebody else.
Thanks.

Надо проверять

[alfim]

Приветствую!

userxp попросил меня отписать здесь о возможных исправлениях для OpenSEF RC5 SP2, так что все "спасибы" и претензии к нему :-)

Итак, корень всех зол заключается в том, что OpenSEF почти всю табличку jos_opensef_sef вытягивает в массив в самом начале своей работы а после этого полным перебором (ужас!) искать там соответствие внутренняю УРЛ - внешняя УРЛ и наоборот. При этом, в случае, если сайт довольно обширный, и ЧПУ на нем много, массив получается просто огроменным. У меня на сайте с 17000 статей ПХП умирал с воем "не хватает памяти" при ограничении в 16Мб. Первый фикс был просто призван уменьшить количество записей, размещаемых в памяти. Но.. не тут-то было. Оказывается, OpenSEF этот же глобальный массив использует для всех-всех ссылок, котрые Джумла пытается привести "человеский вид" (перекрывается ф-я sefRelToAbs). Естесственно, простая фильтрация результатов запроса по REQUEST_URI нас уже не спасет. Пробуем следующий фикс:

В файле administrator/components/com_sef/sef.class.php находим ф-ю lookupOutgoing, комментируем то, что там есть, и заменяем вот этим:

   function lookupOutgoing(  $site_id, $url ) { // static method 
        global $opensef_aliases, $database; 

        $returnaliases = array(); 
/* 
        if ($site_id == null) $site_id = -1; 
        if (count($opensef_aliases) > 0)        { 
        foreach($opensef_aliases as $aliases){ 
                        if ( $aliases->internal == $url ) { 
                                $returnaliases[] = $aliases; 
                        } 
                } 
        } 
*/ 
      if (!count($returnaliases)) 
      { 
          $query = "SELECT * FROM #__opensef_sef WHERE published = '1'" . 
          "\nAND valid = '1'" . 
          "\nAND (direction IS NULL OR direction = '' OR direction = 'o')" . 
          "\nAND internal='$url'". 
          "\nORDER BY site_id DESC, published DESC, valid DESC, LENGTH(direction) DESC limit 1"; 

          $database->setQuery( $query ); 
          if ($database->loadResult()) 
          { 
            $aliases = $database->loadObjectList(); 
            foreach($aliases as $k=>$val) 
            { 
              $returnaliases[] = $val; 
            } 
          } 
      } 

      if (is_array( $returnaliases ) && count( $returnaliases )) { 
      $returnaliases = xclCastObjectList( $returnaliases, 'JosOpenSEFAlias' ); 
      return $returnaliases[0]; 
    } 
    $null = null; 
    return $null; 
  } 

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

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

Спасибо. Жду отзывов.

[murat]

Тестировал на локальном сервере (denwer). После установки хака для файла sef.class.php число запросов (кеширование отключено) с 84 увеличилось до 123. После установки хака для sef.php число запросов стало 122, но появилось несколько notice.

[alfim]

Приветствую!

Суть изменений не в том, чтобы уменьшить количество запросов, а в том, чтобы уменьшить нагрузку на веб-сервер. Я полагаю, что на Вашем локальном сервере очень мало статей (content items), а следовательно, совсем немного записей в таблице jos_opensef_sef (раздел Components - OpenSEF - Manage Friendly URLs). В таком случае подход RC5 себя вполне оправдывает. Проблемы начинаются с увеличением количества записей в jos_opensef_sef. На 3х тысячах sef.php начинает заметно замедляться, и требовать неоправданно большого количества ОЗУ. 8Mb, выделяемых в php.ini по-умолчанию, уже становится недостаточно. Плюс к этому в lookupOutgoing применяется поиск полным перебором, а это просто недопустимо, учитывая то, что данная ф-я вызывается для всех ссылок, имеющихся на странице. Я предлагаю заменить полный перебор запросами к базе MySQL. В случае наличия индексов по полям internal и external таблицы jos_opensef_sef и большого (>5000) количества записей, это работает заметно быстрее, а памяти требует меньше. В файле components/com_sef/sef.php можно вообще закомментировать строки

if ($sefSite->id == null) $sefSite->id = -1;
  $query = "SELECT * FROM #__opensef_sef WHERE published = '1'" .
      "\nAND valid = '1'" .
      "\nAND (direction IS NULL OR direction = '' OR direction = 'o')" .
        "\nAND (site_id IS NULL " .
        ($sefSite->id ? ' OR site_id = ' . $sefSite->id : '') . ')' .
        "\nORDER BY site_id DESC, published DESC, valid DESC, LENGTH(direction) DESC";
    $database->setQuery( $query );
    if ($database->loadResult()) {
    $opensef_aliases = $database->loadObjectList();
  }

Или же применить хак, описанный в 1м посте.

Все мои слова не голословны. Есть живой сайт (адрес не могу светить по причине договоренности с заказчиком, если шибко интересно - пишите в приват), на котором в час пик нагрузка была >1000 одновременных подключений. С оригинальным OpenSEF на выделенном сервере с 2мя гигами ОЗУ и 4-хгигагерцовым процессором страница генерировалась очень долго (от 3х секунд и больше). И это независимо от кеширования (что естесственно, т.к. все записи вытягиваются в sef.php в самом начале работы). После применения описанных изменений, страница генерируется не дольше 0.1 секунды. Думаю, разница заметна. Выводы делайте сами.

Спасибо.

[murat]

У меня на сайте 27 статей. Стоит ли мне применять эти хаки? Ускорится ли зашрузка сайта?

[alfim]

Считаю, что если и ускорится, то очень незначительно. Посмотрите, сколько записей в разделе Components - OpenSEF - Manage Friendly URLs. Их там должно быть не больше 100-200 (если больше -- надо почистить). Я уже писал, что хак имеет смысл применять если записей в меппинг-табличке больше нескольких тысяч.

Проще говоря - Вы можете смело использовать оригинальный OpenSEF RC5 SP2

[userxp]

ну он не совсем оригинальный

[alfim]

Он оригинальный относительно тех изменений, который предлагаю я...

[userxp]

я имел ввиду, что есть "оригинальный" RC5 + к нему SP2.
а я на форуме выкладывал переделанный и локализованный RC5_SP2

[moro]

Товарищи! Сказано: "Если хостер додумался включить кеширование запросов для MySQL - работать будет отлично". На мастерхосте ответили - не включено! Что же делать? имеет смысл использовать приведенные хаки? или подождать Вашего глубокоуважаемого экспертного мнения на этот счет?
На самом деле - это реальная проблема - очень реальная. на сайте - около 300-400 статей и страницы грузятся по 20 секунд. хостер вопит - отрубает периодически. очень неприятно....

[alfim]

Включайте! И дайте знать, если думать будет больше 3х секунд. Не забудьте про индексы для external и internal в табличке joom_opensef_sef.

[murat]

А как включить кэширование запросов для Mysql самостоятельно? У меня тоже хостер masterhost.

[alfim]

Если у Вас есть доступ к /etc/my.cnf файлу, добавьте эти строки:

query-cache-size=50M
query-cache-type=1
key_buffer_size=128M

Первые две строки включают кеширование запросов (с размером памяти можно экспериментировать, вплоть до 20% от общего количества RAM, установленного на сервере. Третья увеличивает объем памяти, отводимого под кеширование ключей и индексов. Тоже можно ставить до 20% от общего количества ОЗУ. Я ставил 5%. Но у меня очень большие нагрузки на веб-сервер (Apache). Экспериментируйте.

В ближайшем будущем собираюсь написать статью об оптимизации сайта с Джумлой и всех ее подводных камнях. Следите за моим блогом .

Если будут какие-то вопросы еще с OpenSEF - не стесняйтесь, задавайте здесь или на блоге.  Чем смогу, помогу.

Удачи!

[murat]

у меня нет доступа к этому файлу.

[alfim]

Тогда добавляйте индексы и пробуйте применить патчи. Не забудьте сделать бекапы изменяемых файлов. Все равно работать будет быстрее, чем с оригинальным OpenSEF. Сколько всего у Вас статей на сайте?

[murat]

немного. А что за индексы и куда их добавлять?

[alfim]

Я уже, по-моему, писал -- если статей немного (меньше 1000), эти патчи Вам не нужны. Все и так работать должно нормально. Если какие-то проблемы и есть, то явно не от OpenSEF.

[moro]

ну вот смотрите, какая картина: стоит Opensef последний,то есть Release Candidate 5 SP2. применен хак из первого поста alfim. проставлены индексы. Хостинг Мастерхост. То есть доступа к конфигурации сервера нет. Ограничения стандартные для этого хостера, то есть крутые. ПЛюс как мы знаем nginx.
Работает шустро сначала (для чистоты эксперимента удалены все ЧПУ). Дальше при 1000 накопившихся ЧПУ - заметные тормоза. При 2000 ЧПУ - половина сайта демонстрирует 502 ошибку, в базе появляется много одинаковых ЧПУ (по два-три на одну и ту же страницу). При этом дебаг joomla показывает, что количество запросов к базе увеличивается в два раза по сравнению с отключенным OpenSEF.

Кто-нибудь видит решение? Такое впечатление, что для обеспечения работы сервера, надо очищать таблицу opensef_sef постоянно.
Отказаться от OpenSEF можно, конечно, но не хочется, потому что сервер давно на нем стоит - поисковики все сожрали... Обидно терять позиции.

[userxp]

на каких компонентах?

[alfim]

moro, надо обязательно применить ОБА хака! ОБЯЗАТЕЛЬНО! Я же писал выше. Один только первый хак уложит вам сайт. Всерьез и надолго. ПРимените, и отпишитесь, пожалуйста.

Спасибо.

[Димитрий]

что значит уложит?  я применил хак из 1го поста, и все очень быстро стало пахать. 1000 статей на сайте.

[alfim]

То и значит . Таблица SEF вырастет быстро, пойдут ошибки типа "you have no access" и так далее. Настоятельно советую применить и второй.

Спасибо.

[murat]

А что вы думаете об этом: http://forum.j-prosolution.com/opensef-fixes/3493-code-optimization.html

[userxp]

с точки зрения пхп это логично

[alfim]

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

[Димитрий]

а подробнее? что значит популярный? и что значит с большим количеством статей? сколько заходов и сколько статей?

[alfim]

Димитрий, я уже писал выше про ограничения. В числовом виде. Перечитайте еще раз

[Димитрий]

Включайте! И дайте знать, если думать будет больше 3х секунд. Не забудьте про индексы для external и internal в табличке joom_opensef_sef.

я перешел на быстрый хостинг firstvds, и пошли тормоза с сефом.. 1000 статей,посещаемость 60 человек в день.
генерится по 10 секунд. что делать?
что за индексы, про которые вы пишите?

[alfim]

Индексы на соответсвующие поля в табличке jos_opensef_sef
А хаки Вы применяли?

[Димитрий]

оба хака применил. все равно не понимаю, что за индексы. обьясните, если не сложно- для тех, кто в танке- что надо сделать? могу зайти через phpmyadmin и сделать данное действо.
когда я был на другом хостинге все летало, сегодня перешел- сделал полную копию. сначала SEF показалось вообще не работал. просто висяк полный.  посмотрел логи, там везде 404 стоит от яндекса-бота.
потом переставил openSEF, стало жутко долго открывать- 10-20 секунд.

[alfim]

через майАдмин как раз и добавляются эти индексы. Зайдите в структуру таблицы, там где-то оно есть

[Димитрий]

а как их добавлять? может подробнее все же немного для ламера?

[Димитрий]

вижу такую колонку создать индексы- однако для скольки рядов? как? я нажал для всех рядов, 7000 с лишним. выскочила какая-то дребедень. не вручную же все 7000 выборов делать..
в итоге браузер просто завис насмерть..пришлось его закрыть

[alfim]

Ох... Если бы я помнил

Во-первых, насколько я понял, Вы переустановили OpenSEF, следовательно, оба хака исчезли. Значит, индексы Вам не помогут.

Во-вторых, расскажите, как Вы переносили сайт на новый хостинг. В частности, как перенесли базу данных? Не забыли ли таблички jos_opensef_*?

В-третьих, зайдите в майАдмин, выберите базу, выберите табличку jos_opensef_sef и в списке полей найдите иконку Индекс напротив соответствующего поля. Кликните его, и будет Вам счастье .

[Димитрий]

я перезалил старый файл, который у меня был с хаками. уж не совсем я ламер. базу я перенес полностью, 100%, однако потом переустанавливал openSEF.
что за соответствующее поле? оно всего одно?

[alfim]

Дима, у тебя аська есть? Стучись, мой номер 142806591

[Димитрий]

хорошо напишу. кстати все сделал. у меня еще джре кэш стоит..

[Dutch]

Товарищи! Сказано: "Если хостер додумался включить кеширование запросов для MySQL - работать будет отлично". На мастерхосте ответили - не включено! Что же делать? имеет смысл использовать приведенные хаки? или подождать Вашего глубокоуважаемого экспертного мнения на этот счет?
На самом деле - это реальная проблема - очень реальная. на сайте - около 300-400 статей и страницы грузятся по 20 секунд. хостер вопит - отрубает периодически. очень неприятно....

Чесно сказать меня мастерхост очень бесит.
Я работаю с сайтом web-mama.ru, который хостится на этом "прекрасном" хосте.
так вот на диалапе сайт грузится секунд 30-40, на выделенке до 8-10.
Это при том что хостинг находится в Москве или Питере, а сижу во Львове.
Жуть полная.
Чесно говоря лучше выбрать получше хостинг.
Кстати рекомендую украинские хостинги.
На сегодня в Украине появилось несколько датацентров из скоростными линиями.
Ну и к тому же хостинг дешевле.

[murat]

У меня мастерхост. После переноса моего сайта на новый сервер с новым ПО, сайт стал просто летать.

[era]

У меня мастерхост. После переноса моего сайта на новый сервер с новым ПО, сайт стал просто летать.

они его наверное не успрели забить клиентами ещё

[murat]

После 15 мая будет видно. Потому что этого числа они всех перенесут на новое ПО.

[Gans]

Я уже, по-моему, писал -- если статей немного (меньше 1000), эти патчи Вам не нужны. Все и так работать должно нормально. Если какие-то проблемы и есть, то явно не от OpenSEF.

А если инет магазин то это значит если товаров больше 1000 то нужно хак ставить я так понимаю?
И еще вопросик на joomlaportal.ru появился компонент для Joomla PageCache стоит ли его применять для уменьшения нагрузки в сочитании с OpenSEF?

[userxp]

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

[Ctrelok]

Добрый вечер!
поставил первый фикс на свой сайт viktur.ru - и о чудо!!! все залетало.
у меня 850 страниц контента, посещаемость 400-450 в день. в свое время замучился ужасно с этим open-sefom
и на что только не грешил из-за сверх тормознутости генерации страниц - даже на valuehost.
хотел уже даже сменить его, но поставил для пробы на нем второй сайт (без open-sef) - все летает.
у меня вопрос- если теперь все быстро генирится с первым фиксом, нужно ли ставить второй? или от добра добра не ищут???
спасибо.

[mik-a-el]

Применил первый хак - стало рости число урлов в таблице опенсефа. Причем сопоставляются те же самые адреса. Кто-нить еще это наблюдает?
Их количество возросло уже почти в 10 раз.

[userxp]

мля, народ!
ну написано же - применять ОБА хака СРАЗУ!

[mamahtehok]

Приминил оба патча индексы проставил но что то не заметил ни фига прироста, в базе более 5000 записей

[Ctrelok]

а у меня гораздо быстрее работать стало (1000 контента). а то уж было хотел отказаться от open-sef и потерять все проиндексированные страницы и позиции в яше

[Arina]

мля, народ!
ну написано же - применять ОБА хака СРАЗУ!

А второй хак где ?
Подозреваю первый хак этот:
RE:
В файле administrator/components/com_sef/sef.class.php находим ф-ю lookupOutgoing, комментируем то, что там есть, и заменяем вот этим:

   function lookupOutgoing(  $site_id, $url ) { // static method
        global $opensef_aliases, $database;

        $returnaliases = array();
/*
        if ($site_id == null) $site_id = -1;
        if (count($opensef_aliases) > 0)        {
        foreach($opensef_aliases as $aliases){
                        if ( $aliases->internal == $url ) {
                                $returnaliases[] = $aliases;
                        }
                }
        }
*/
      if (!count($returnaliases))
      {
          $query = "SELECT * FROM #__opensef_sef WHERE published = '1'" .
          "\nAND valid = '1'" .
          "\nAND (direction IS NULL OR direction = '' OR direction = 'o')" .
          "\nAND internal='$url'".
          "\nORDER BY site_id DESC, published DESC, valid DESC, LENGTH(direction) DESC limit 1";

          $database->setQuery( $query );
          if ($database->loadResult())
          {
            $aliases = $database->loadObjectList();
            foreach($aliases as $k=>$val)
            {
              $returnaliases[] = $val;
            }
          }
      }

      if (is_array( $returnaliases ) && count( $returnaliases )) {
      $returnaliases = xclCastObjectList( $returnaliases, 'JosOpenSEFAlias' );
      return $returnaliases[0];
    }
    $null = null;
    return $null;
  }
-----------------------------------------------------------------------------------------

А второй хак где ?

[userxp]

это второй. первый в моём первом сообщении

[omvitamin]

А я вот сначала хотел поставить и OpenSef и эти 2 хака, а потом посмотрел что у меня 870 страниц контента и 846 из них проиндексированы - и решил просто поствить Хак для метатэгов и всё. сайт прекрасно индексируется в принципе. Да и вообще сами вебмастера ещё е определилсь что лучше ссылки типа index.php?name=Files&op=view_file&lid=864 (извиняюсь за вид ссылки аля php-nuke)  или ЧПУ. Много знаю людей плюют на эти псевдо-СЕО и получают 420 тИЦ за 2 АПа, при этом не тратясь на расркрутку.
Поэтому я бы не советовел ставить SEF тем у кого уже есть хорошие позиции в Яшке и Webalta .

К тому же сайт у меня не на личном серваке, а на стороннем хостинге..поэтому тормоза ещё те. Пробовал даже на практически пустую joomla ставить openSef и эти 2 хака. всеравно тормоза не понравились.
Хостинг Slavhost 

[Akcium]

все отлично, залетало, СПАСИБО!

[alxsz]

Всем привет, интересует такой вопрос:
Кто нибудь пробовал использовать open sef с связкой iJoomla news portal ?

Замечены такие такие проблемы:

1)Без использования приведенных хаков в этой теме -
При появлении окола 4500 ссылок нагенерирующихся компонентом - главная страница ( компонент news portal ) перестает отображаться - видна только шапка.

2) с применением хаков - все отображается на ура, но (!) при первом посещении статьи не с главной страницы, статья не открывается как должна открываться с новым url а просто перебрасывает на главную с url стандартного sef компонента...
Конечно если потом повтрно зайти в тот раздел то ссылка уже преобразованна. Но получается что каждый раз нужно заходить по ссылке 2 раза...

Видимо проблемы в том что в качестве главной страницы используется сторонний компонент...

Может кто нибудб подскажет возможность решение проблемы?

[Sevenor]

Поставил оба хака, пока изучаю, но есть проблема, при добавлении статей, сайт зависает секунды на 3.