Использование $ _SESSION для буферизации/кэширования запросов MySQL

Question

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

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

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

Вопросы:

1. Возможно ли это? Есть ли способ выполнить функцию, когда сеансы уничтожаются таймаутом или закрытием браузера?

2. Является ли это чувствительным? Есть несколько сотен параллельных запросов SQL, которые будут проблемой для общего сервера, и идея использования $_SESSION в качестве буфера, предназначенного для смягчения некоторых из этих проблем.

Answer 1

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

Итак ... Предлагаю вам использовать либо кеш-систему с общей памятью (RAM), такую ​​как memcache (если ваш хостер предлагает), либо систему на основе диска.

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

Answer 2

Есть ли способ выполнить функцию, когда сеансы уничтожены на таймаутом или закрытием браузера?

Да, но это может не сработать, как вы себе представляете. Вы можете определить свой собственный обработчик сеанса, используя session_set_save_handler, а часть определения включает функции обратного вызова destroy и gc. Эти два вызова вызываются, когда сеанс уничтожается явно и когда он уничтожается из-за истечения срока действия, поэтому они делают именно то, что вы просите.

Однако истечение срока действия в связи с таймаутом не происходят с точностью часовой стрелки; это может быть очень много времени, прежде чем истекший сеанс на самом деле «собранный мусором». Кроме того, сборщик мусора запускает probabilistically, поэтому в теории есть вероятность того, что истекшие сессии будут никогда не собирать мусор.

Является ли это чувствительным? Являются ли несколько сотен параллельных SQL-запросов проблемой для общего сервера и идея использования $ _SESSION в качестве буфера, предназначенного для смягчения некоторых из этих проблем.

Я действительно не хотел бы сделать это по нескольким причинам:

• Преждевременная оптимизация (перед измерением, не только предположить, что это будет «лучше»).
• Сессия никогда не может быть собрана мусором; даже если этого не происходит, вы не контролируете , когда их собирают. Это может быть проблемой.
• Существует возможность потерять все, что содержит сессия (например, перезагрузка сервера), которая включает в себя прогресс игрока. Игрокам не нравится проигрывать прогресс.
• Параллельные сеансы для одного и того же пользователя были бы невозможны (чьи «сохраненные данные» выигрывают и остаются в базе данных?).

Что относительно альтернатив?

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

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

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

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

Answer 3

На самом деле вы можете использовать $ _SESSION в качестве буфера, чтобы избежать дублирования чтения, мне кажется, что это хорошая идея (memcached даже лучше, чем это), конечно, не для задержки написания (что гораздо сложнее и должно быть обработано db);

вы можете использовать простой хэш, сохраненное в $ _SESSION

$cache = array(); 
$_SESSION['cache'] = $cache; 

тогда, когда вы должны сделать запрос

if(isset($_SESSION['cache'][$id]){ 
    //you have a cache it 
    $question = $_SESSION['cache'][$id]; 
}else{ 
    //no cache, retrieve your $question and save it in the cache 
    $_SESSION['cache'][$id] = $question ; 
} 

Answer 4

Это бы бессмысленно? Является ли несколько сотен параллельных SQL-запросов проблемой для общего сервера и является идеей использования $ _SESSION в качестве буфера, чтобы облегчить часть этого.

No. Прежде всего, вы никогда не знаете, что происходит с сеанса (выход из системы, очевидно, где тайм-аут почти невозможно обнаружить), так что это не надежный механизм кэширования в любом случае. Если есть результаты, которые вы запрашиваете несколько раз по диапазону нескольких запросов, которые не меняются слишком часто, сохраните результаты этих запросов в выделенном кэширующем механизме, таком как APC или memcached.

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

Кроме того, написание порядочных вопросов более важно; качество вашего дизайна и запросов более важно, чем количество. Если вы правильно оцениваете свою схему, индексы и запросы, 10 запросов быстрее, чем один запрос, который не оптимизирован. Я бы потратил свое время на изучение того, как писать эффективные запросы, и читать по индексированию, а не пытаться преодолеть проблему с «обходным путем», например, кэширование в сеансе.

удачи, я надеюсь, что ваш сайт становится, что большой успех вам будет на самом деле нужен совет выше;)