Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Оптимизировать подключение к бд
Покинул форум
Сообщений всего: 8
Дата рег-ции: Янв. 2015
Помог: 0 раз(а)
Здравствуйте. На сайте есть вывод количества зарегистрированных клиентов и подсчет рейтинга на основании комментариев (сделано на php). При выполнении любой страницы сайта идет соединение с БД и считаются данные, что наверно не очень хорошо сказывается на быстродействии. Возможно ли как нибудь сделать так, чтобы запрос производился 1 раз в сутки, а данные из запроса отображались постоянно?
Тоесть, есть например 100 зарегистрированных клиентов. Эта цифра отображается в хедере сайта. За день зарегистрировалось 3 человека. В 00.00 цифра стала 103. И на следующий день до 00.00 отображается 103
Копал в сторону cron. На хостинге его легко можно включить, из админки. Но не понимаю как отображать данные которые считались с бд, если соединение с бд будет раз в сутки
skiphog
Отправлено: 28 Января, 2015 - 17:07:54
Частый гость
Покинул форум
Сообщений всего: 139
Дата рег-ции: Дек. 2014 Откуда: Киров, Россия
Помог: 11 раз(а)
Для этого cron вам не нужен.
Закешируйте уже готовые данные в мемкеш или в файл и тяните их оттуда.
Обновляйте кеш, только тогда, когда кто-то зарегистрируется.
GoDr
Отправлено: 28 Января, 2015 - 17:13:43
Посетитель
Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015 Откуда: Тамбов
Помог: 17 раз(а)
Что мешает кешировать запрос, например в файле?
Т.е. :
- проверяется наличие файла с кешем
- проверяем его "срок годности". Допустим ему больше 24 часов и время 00:00:01
- запрашиваем данные из БД
- переписываем файл кеша с новыми данными
- выводим результат
Если в течении недели не было обращений на сайт, то и запросов никаких не будет вообще.. в отличие от cron`а (Добавление)
пока писал, уже мысль озвучили
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
ну виполнять перерасчет за счет пользователя (он же будет жать пока будет подсчет) плохо. все таки крон раз в сутки очень даже неплохо учитивая то, что это обичный хостинг.
Тянуть с файла все равно бистрее подсчета
GoDr
Отправлено: 28 Января, 2015 - 18:22:03
Посетитель
Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015 Откуда: Тамбов
Помог: 17 раз(а)
да о чём вы вообще говорите?????? Это МАГАЗИН!!!! Да там при открытии главной страницы будет дай бог минимум сотня запросов! И не просто безобидный запрос
а очень даже мощные... Глупо взять с собой на борт Боинга канистру керосина (Добавление)
.
Кстати
Цитата:
COUNT(*) is optimized to return very quickly if the SELECT retrieves from one table, no other columns are retrieved, and there is no WHERE clause. For example:
mysql> SELECT COUNT(*) FROM student;
This optimization applies only to MyISAM and ISAM tables only, because an exact record count is stored for these table types and can be accessed very quickly. For transactional storage engines (InnoDB, BDB), storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
GoDr пишет:
И не просто безобидный запрос
Ой далеко не безобидный.
Читать xmin/xmax каждой записи для текущей транзакции, чтобы узнать, существует ли эта запись.
На моём стенде сейчас никчёмные 400к записей считаются аж 0,1с (без query cache, но данные уже прогреты).
Да в такое время джойн на пяток таблиц впихнуть запросто можно.
----- PostgreSQL DBA
GoDr
Отправлено: 28 Января, 2015 - 19:27:58
Посетитель
Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015 Откуда: Тамбов
Помог: 17 раз(а)
ну уж не знаю что читать
Чистый запрос без каких либо условий, судя по документации очень даже оптимизирован...
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Вот что процитировали из документации - то и читать.
GoDr пишет:
For transactional storage engines (InnoDB, BDB), storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.
Нет транзакционности хранилища - значит нет данных.
----- PostgreSQL DBA
GoDr
Отправлено: 28 Января, 2015 - 20:55:16
Посетитель
Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015 Откуда: Тамбов
Помог: 17 раз(а)
Мелкий, ну понятно что при условии..........
И я не знаю от куда у тебе такие данные, но вот сейчас сделал пробную табличку 150000 записей
(Добавление)
.
PS
наверное что-то прокешировалось.. уже не могу повторить такой результат: не даёт больше 0,001 sec. (Добавление)
.
Самый худший результат
Цитата:
Starting 8 µs
Waiting For Query Cache Lock 2 µs
Checking Query Cache For Query 23 µs
Checking Permissions 3 µs
Opening Tables 21 µs
System Lock 5 µs
Waiting For Query Cache Lock 16 µs
Init 9 µs
Optimizing 4 µs
Statistics 8 µs
Preparing 6 µs
Executing 2 µs
Sending Data 31.9 ms
End 10 µs
Query End 3 µs
Closing Tables 8 µs
Freeing Items 4 µs
Waiting For Query Cache Lock 1 µs
Freeing Items 162 µs
Waiting For Query Cache Lock 2 µs
Freeing Items 1 µs
Storing Result In Query Cache 2 µs
Logging Slow Query 1 µs
Cleaning Up 1 µs
(Добавление)
.
Сбросил кеш
Цитата:
Starting 9 µs
Waiting For Query Cache Lock 2 µs
Checking Query Cache For Query 23 µs
Checking Permissions 4 µs
Opening Tables 13 µs
System Lock 6 µs
Waiting For Query Cache Lock 10 µs
Init 9 µs
Optimizing 4 µs
Executing 5 µs
End 2 µs
Query End 1 µs
Closing Tables 5 µs
Freeing Items 2 µs
Waiting For Query Cache Lock 1 µs
Freeing Items 43 µs
Waiting For Query Cache Lock 2 µs
Freeing Items 1 µs
Storing Result In Query Cache 2 µs
Logging Slow Query 1 µs
Cleaning Up 3 µs
(Добавление)
наверное нужно миллиона три сделать и проверить.. но уж слишком долго забивать запросы...
А с MyISAM даже не могу получить одну тысячную секунды (Добавление)
хотя с другой стороны... 400000 зарегистрированных пользователей - можно только позавидовать такому сайту
Да и само число пользователей с сервера клиенту будет идти дольше ))))) А если ещё если представить в одном запросе 5-7 JOIN, эти циферки покажутся смешными...
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
MyISAM я в принципе обсуждать не собираюсь. Он не транзакционен. Добавить к этому мне нечего. Только innodb.
В общем-то, моя стендовая машина, где сейчас есть под рукой достаточного размера таблицы - это mysql 5.1.73, запущенный в openvz контейнере, hwnode которого - Xen PV домен. Производительности эта матрёшка явно не добавляет. Но для dev-машины это даже плюс.
И чтобы не искать микросекунды, возьмём табличку малость побольше:
Цитата:
mysql> select SQL_NO_CACHE count(*) from brt_rating;
+----------+
| count(*) |
+----------+
| 49487707 |
+----------+
1 row in set (10.78 sec)
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.