Поговорим о кешировании :)

Статус
Закрыто для дальнейших ответов.

FiRеFоX

V.I.P.
Регистрация
07.08.2010
Сообщения
744
Дело было вечером, делать было нечего, я как обычно сидел за компом и пил кофе тупо смотря в код. Нужно было делать кое-что важное в этом коде (хотя это делать и до сих пор надо), но мне было не охото. Искал в коде какую-нибудь недоделку или ещё-что, что можно было переделать или исправить. Ну да, мне больше нравится исправлять ошибки в коде и искать всякие баги, чем делать что-то новое. Короче, дернул меня черт залезть в функцию, отвечающую за авторизацию. Была она примерно она такая:
Код:
function user_autoriz($post_id_login = false, $post_pass = false) {
    if($post_id_login && $post_pass) {
      //обработка переменных
      $res = select("SELECT ... WHERE `id` = $id AND `pass` = $pass");
    }
    elseif($_SESSION['id']) {
     $res = select("SELECT ... WHERE `id` = ".intval($_SESSION['id']));
    }
    elseif($_COOKIE['id'] && $_COOKIE['pass']) {
      //Почти тоже самое что в первом if()
    }
    else {
      $res = false;
    }
    return $res;
}
Глянул я сюда и вижу, что при каждом обращении к страницам сайта идет авторизация через сессию(если юзер был авторизован до этого через куку или пост) и там запрос к базе. Думаю: "Нах..я при каждом обращении юзера к сайту делать запрос к базе? Закешируем ка мы это дело куда-то в отдельный файл или сессию". Ну и сделал вот так:
Код:
if($_SESSION['data_scan_mysql'] >= time() && is_array($_SESSION['user_info'])) {
   $res = $_SESSION['user_info'];
}
else {
  $res = select("SELECT ... WHERE `id` = ".intval($_SESSION['id']));
  $time_tmp = 60;
  $_SESSION['user_info'] = $res;
  $_SESSION['data_scan_mysql'] = time() + $time_tmp;
}
Тестанул на паре страниц, вроде все ок и работает. Закрыл нотепад и пошел спать. Утром встаю - тут баг, там баг. Думаю, да че мл.. за фигня то, вчера же всё было нормально. Хотя это даже не баги. Ну, например, Пишу сам себе письмо с разных аккаунтов, а оно приходит только через ~ 60с. Я как кусок идиота полез в скрипт писем, из головы вообще вылетело, что я вчера сделал это кеширование. Около часа сидел в коде писем и искал баг, но так и не нашел его. За одно пока искал баг, ещё и доделал подписку на форуме, про которую спрашивал тут на форуме уже давненько. Потом, правда, вспомнил, что сделал это супер-кеширование запроса.
Итак. сам вопрос:
Забить болт на этот запрос к базе и оставить как есть и пускай будет запрос или же доделать это якобы кеширование запроса до нормального состояния?
Вроде бы 1 запрос, но с 1к юзеров, это 1к запросов. В моей прошлой игре, некоторые юзеры, кто сидел с компов умудрялись обновлять страницы по 1 разу в секунду. Ну да, там важно время в боях было, типа когда использовать эликсир, когда умение или ещё что-то. Секунды имели значение.

P.S Возможно, что это можно было бы как-то решить на уровне MYSQL-кеширования, но в кешировании MYSQL я тупой как пробка.
P.P.S Вот только не надо в меня тыкать пальцем и кричать "Кешировать надо ресурсоемкие участки кода и тяжелые запросы mysql или данные которые, редко изменяются". Сам знаю :) Но вот про эту авторизацию у меня как-то мнение разделилось: Вроде бы и можно закешировать в сессию, а с другой стороны нафиг оно надо. Запрос же не такой уж и гигантский.
Вобщем поделитесь своими мнениями :)
 

lekzd

parse error: parse error, unexpected T_STRING...
Регистрация
17.02.2011
Сообщения
1 125
А почему просто не писать в сессию что юзер залогинен?
 

FiRеFоX

V.I.P.
Регистрация
07.08.2010
Сообщения
744
А почему просто не писать в сессию что юзер залогинен?
Потому что 99% страниц сайта доступны только авторизованным юзерам.
Допустим тот же форум у меня в игре, там темы можно создавать только с N уровня персонажа у игрока и оставлять комменты тоже можно только с N уровня. Придется делать отдельный запрос в таблицу юзеров, а так я сразу через функцию провожу авторизацию и выдаю массив всей важной инфы об пользователе. Или, например, игроку отправляют внутриигровое письмо, я обновляю эту главную таблицу у юзеров [`count_new_pm` = `count_new_pm` + 1]. Иначе бы тогда пришлось делать доп.запросы.
На страницах это выглядит примерно так:
Код:
$user = user_autoriz();
if(is_array($user)) {
   //Верхнее (топ-меню)
    if($user['count_new_pm']) {
	  $HTML .= 'У вас новое личное сообщение';
   }
   if($user['count_new_forum']) {
	  $HTML .= 'У вас на форуме есть непрочитанные сообщения';
   }
   if($user['id_bitva'] > 0) {
	  $HTML .= 'Вы находитесь в бою!';
   }
   //Середина, например форум
   if($user['uroven'] > 5) {
	  //Выводим форму для создания темы
   }
   else {
	  $HTML .= 'На форуме можно создавать темы только с N уровня';
   }
   //и т.д
}
else {
   $HTML .= user_autoriz_false();
}
echo $HTML;
 

lekzd

parse error: parse error, unexpected T_STRING...
Регистрация
17.02.2011
Сообщения
1 125
Потому что 99% страниц сайта доступны только авторизованным юзерам.
Так а почему нельзя просто писать в сессию все что надо? Единственное, что, после изменения настроек юзера, снова забивать в сессию новые параметры

АААААААААА!!!!!!
 

FiRеFоX

V.I.P.
Регистрация
07.08.2010
Сообщения
744
Так а почему нельзя просто писать в сессию все что надо? Единственное, что, после изменения настроек юзера, снова забивать в сессию новые параметры
Так тогда будут отдаваться закешированные в сессии параметры, причем все. Допустим, что юзер 1 написал письмо юзеру 2, а т.к у "юзера 1" параметр о письмах сохранен в сессию, то данные будут браться оттуда из его сессии и будет показываться на странице, что письма ещё нет, хотя оно же уже пришло. Нельзя никак юзером 1 изменить сессию юзеру 2, например переменную, отвечающую за число новых пришедших писем? Или как-то другим способом показать юзеру 2, что какие-то параметры у него были изменены?
Объясните почему такая реакция?
 

lekzd

parse error: parse error, unexpected T_STRING...
Регистрация
17.02.2011
Сообщения
1 125
Нельзя никак юзером 1 изменить сессию юзеру 2, например переменную, отвечающую за число новых пришедших писем?
меняйте логику своих рассуждений, почему бы самому юзеру не подсчитывать свои входящие?

Объясните почему такая реакция?
echo в коде модуля, это же плохо, как же отделение логики от представления?
 

CamaroSS

Well-Known Member
Регистрация
21.02.2012
Сообщения
176
Реальные посоны шаблонизируют всё, что шаблонизируется ;)

А если серьёзно, то очень трудно такое поддерживать/править, особенно когда некоторые товарищи так таблицы выводят, с td/tr в самых неожиданных местах.
Да я и сам когда-то так делал ))

Нельзя никак юзером 1 изменить сессию юзеру 2, например переменную, отвечающую за число новых пришедших писем?
Если сессия в базе, то можно, но лучше так не делать.
 

FiRеFоX

V.I.P.
Регистрация
07.08.2010
Сообщения
744
ААААА!
echo в коде модуля, это же плохо, как же отделение логики от представления?
Это не в коде модуля, для примера написал, чтобы было понятно какая примерно структура. В коде модулей у меня вообще никаких выводов нет, даже если вдруг вылезут ошибки, то идут в буфер, чтобы потом их отловить, а весь остальной контент для юзера идет в переменную $HTML. В конце страницы вызывается функция по выводу данных в браузер:
Код:
function generic_html($text, $type_doc) {
 //Тут генерируется шапка, низ, ещё всякие проверки, типа доступа и т.д
 echo $text;
}
Если это тоже не правильно, то поправьте, как правильно. Буду признателен.
меняйте логику своих рассуждений, почему бы самому юзеру не подсчитывать свои входящие?
Зачем? Это лишний запрос в базу по поиску новых писем при каждом обращении к сайту. Или делать эту проверку каждые N сек? Не проще при отправке письма изменять какое-то поле у получателя письма, например прибавить там +1? Нагрузка сократится в несколько раз. Или я не прав?
 

lekzd

parse error: parse error, unexpected T_STRING...
Регистрация
17.02.2011
Сообщения
1 125
Или делать эту проверку каждые N сек?
Чаще делают так, нет нужды при каждой загрузке проверять письма, куда важнее каждый раз проверять, чтобы юзер имел привилегии на доступ.

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

FiRеFоX

V.I.P.
Регистрация
07.08.2010
Сообщения
744
логика раздельных модулей нарушается, если не планируется ничего переписывать, то можно и так оставить, но на перспективу подход не очень.
А в последствии с какими трудностями можно будет столкнуться, если оставить так?
 
Статус
Закрыто для дальнейших ответов.
Верх Низ