Хранение посетителей сайта без завершения соединений MySQL

Question

У нас есть приложение для аналитики, которое позволяет пользователям запускать несколько разных отчетов. У нас есть одна базовая настройка базы данных master-slave.

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

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

Запрос, который вызывает блокировками:

SELECT VisitID,VistSourceID 
FROM visitorvisits 
LEFT JOIN visitornumbers 
ON VinuVlviID=VlviID 
WHERE vistNosID='12345' AND 
VistCampaignID='1' AND 
('2013-04-03 14:30:48' >= DATE_ADD(VistDateStart, INTERVAL VistTimeStart HOUR_SECOND)) 
AND ('2013-04-03 14:30:48' <= DATE_ADD(VistDateEnd, INTERVAL VistTimeEnd HOUR_SECOND) 
OR VistStatusCode='1') 

expalin на этом stament является:

+----+-------------+--------------------------+--------+-----------------------------------------------------------------------------------+----------------+---------+----------------------------------------------+------+-------------+ 
| id | select_type | table     | type | possible_keys                  | key   | key_len | ref           | rows | Extra  | 
+----+-------------+--------------------------+--------+-----------------------------------------------------------------------------------+----------------+---------+----------------------------------------------+------+-------------+ 
| 1 | SIMPLE  | visitornumbers   | ref | idx_vistNosID,idx_visitNosVisitID              | idx_vistNoID | 4  | const          | 4527 | Using where | 
| 1 | SIMPLE  | visitorvisits   | eq_ref | PRIMARY,idx_VistCampaignID,idx_VistStatusCode,idx_VistCampaignID_VistDateStart_VistVistorID | PRIMARY  | 4  | mhdblive.visitorvisits.visitNosVisitID | 1 | Using where | 
+----+-------------+--------------------------+--------+-----------------------------------------------------------------------------------+----------------+---------+----------------------------------------------+------+-------------+ 

Answer 1

Вы полностью закрывать соединения каждый раз?

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

Возможно, запись информации в фиксированное место, например текстовый файл, и задание CRON, которое выполняется каждые 30 секунд или около того для обработки содержимого этого файла (ов).

Возможно, HTTP-вызов страницы на вашем сайте, которая хранит данные в массиве переменных сеанса, а затем уничтожает переменные сеанса и сохраняет все данные в таблице каждые 30 секунд или около того.

Answer 2

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

Далее - проверьте количество подключений, на которые настроен ваш сервер MySQL; на Linux, с достаточным объемом оперативной памяти, вы сможете поддерживать тысячи открытых подключений; если ваше приложение открывает соединения только тогда, когда оно им необходимо, что примерно соответствует количеству одновременных запросов к странице, которые вы поддерживаете (и каждый запрос страницы должен выполняться в миллисекундах). Возможно, вы достигли этого уровня, но, как правило, есть другие узкие места, которые вы достигаете на этом уровне (базовый процессор, как правило).

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

Вы можете использовать свое собственное решение или использовать один из многих серверов очереди (например, Beanstalk, Amazon SQS, RabbitMQ).