Перейти к контенту

Как мы ломали

  • записи
    24
  • комментариев
    147
  • просмотра
    16 233

Последние темы


MiksIr

315 просмотров

А что думаете про такую вот штуку.

newposts.php

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

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

10 комментариев


Рекомендуемые комментарии

Интересная мысль.) Если каждые две минуты на "Последние темы" кликает 1000+ человек, то толк должен быть.

 

Из минусов на беглый взгляд:

 

1). Если обращения к "Новым сообщениям" будут реже, чем раз в 120 секунд, то мы только снизим скорость выдачи страницы. Три запроса вместо одного + основной поисковый запрос будет возвращать больше данных, чем обычный. За счет времени (как минимум, за одни сутки) + сразу из всех форумов.

 

2). Периодически будут случаться ситуации, при которых тема была перемещена\удалена\скрыта\изменена. Или в неё попросту отпостили. Реальное положение вещей изменилось, а кеш ещё живёт.

 

В результате -> сообщения от юзеров: "Нажал новые сообщения, нажал тему, получил ошибку". Или "время последнего ответа некорректно".

Ссылка на комментарий

Да, 120 секунд был временный вариант - нужно делать ревалидацию кеша на постинге. Удаление/перемещение тем может составить проблему - спасибо за акцент, нада будет подумать.

 

С запросами, кстати, в исходном инвижене, насколько я помню, при нажатии просмотра последних сообщений для юзера создается запись в таблице поиска, потом редирект, чтение этой записи и, собственно, сам запрос. Т.е. одним там и не пахнет =) Причем, там все форумы идут списком в IN, а форумов то много =)

Ссылка на комментарий

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

 

IN это да.. неизбежное зло. Как вариант, можно сразу создать 3-4 закрытых раздела для внутренних тёрок, а в условие в search.php жестко прописать 'AND t.forum_id>5'. Предполагая, что форумы дальше пятого - все открытые.

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

Ну да, но дело в том, что они генерируют SQL строку (не делая запрос) и кладут ее в кеш.

IN это да.. неизбежное зло. Как вариант, можно сразу создать 3-4 закрытых раздела для внутренних тёрок, а в условие в search.php жестко прописать 'AND t.forum_id>5'. Предполагая, что форумы дальше пятого - все открытые.

Не, это несерьезно. Работая с форумом мы сквозь пальцы смотрим на всякие костыли, но все же прописывание айдишников в коде стараемся избегать - сами потом концов не найдем.

Ссылка на комментарий

Отключенные в админке форумы для поискового запроса, кстати, тоже один из генераторов-причин этого длиного IN...

 

Тут речь была как-то уменьшить километровые списки в IN - заменить их искуственно на одно-два условия "больше-меньше" - хотя не уверен, что выборка по больше-меньше сильно выгоднее IN списка для БД.

 

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

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

 

Совершенно согласен.

 

Не, это несерьезно. Работая с форумом мы сквозь пальцы смотрим на всякие костыли, но все же прописывание айдишников в коде стараемся избегать - сами потом концов не найдем.

 

Разумеется, такие вещи если и делаются, то выносятся в настройку. Подразумевался кусок готового запроса, уходящего на выполнение.

Ссылка на комментарий
Не, тяжко. Просто это можно делать, если с форумом работают программисты, а менеджеры к добавлению новых форумов не подпускаются. Но если это так - необходимость всей админки становится сомнительной =) Иначе же, добавление менеджером нового закрытого форума принесет веселье всем =)
Ссылка на комментарий
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.