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 :: Оптимизировать подключение к бд

 PHP.SU

 Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (2): [1] 2 »   

> Описание: Оптимизировать подключение к бд
Поиск в теме | Версия для печати
SWORDMAN
Отправлено: 28 Января, 2015 - 16:33:32
Post Id


Новичок


Покинул форум
Сообщений всего: 8
Дата рег-ции: Янв. 2015  


Помог: 0 раз(а)
Здравствуйте. На сайте есть вывод количества зарегистрированных клиентов и подсчет рейтинга на основании комментариев (сделано на php). При выполнении любой страницы сайта идет соединение с БД и считаются данные, что наверно не очень хорошо сказывается на быстродействии. Возможно ли как нибудь сделать так, чтобы запрос производился 1 раз в сутки, а данные из запроса отображались постоянно?

Тоесть, есть например 100 зарегистрированных клиентов. Эта цифра отображается в хедере сайта. За день зарегистрировалось 3 человека. В 00.00 цифра стала 103. И на следующий день до 00.00 отображается 103

Копал в сторону cron. На хостинге его легко можно включить, из админки. Но не понимаю как отображать данные которые считались с бд, если соединение с бд будет раз в сутки
 
 Top
skiphog
Отправлено: 28 Января, 2015 - 17:07:54
Post Id



Частый гость


Покинул форум
Сообщений всего: 139
Дата рег-ции: Дек. 2014  
Откуда: Киров, Россия


Помог: 11 раз(а)
Для этого cron вам не нужен.

Закешируйте уже готовые данные в мемкеш или в файл и тяните их оттуда.
Обновляйте кеш, только тогда, когда кто-то зарегистрируется.
 
My status
 Top
GoDr
Отправлено: 28 Января, 2015 - 17:13:43
Post Id



Посетитель


Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015  
Откуда: Тамбов


Помог: 17 раз(а)
Что мешает кешировать запрос, например в файле?
Т.е. :
- проверяется наличие файла с кешем
- проверяем его "срок годности". Допустим ему больше 24 часов и время 00:00:01
- запрашиваем данные из БД
- переписываем файл кеша с новыми данными
- выводим результат

Если в течении недели не было обращений на сайт, то и запросов никаких не будет вообще.. в отличие от cron`а
(Добавление)
пока писал, уже мысль озвучили Радость


-----
Система управления веб-содержимым Lotos CMS
 
 Top
SWORDMAN
Отправлено: 28 Января, 2015 - 17:27:00
Post Id


Новичок


Покинул форум
Сообщений всего: 8
Дата рег-ции: Янв. 2015  


Помог: 0 раз(а)
Запросы будут, живой магазин, клиенты каждый день регистрируютсяУлыбка Но ваш вариант несомненно лучше. Спасибо обоим за заданное направление! Выпьем!

Буду благодарен ссылке с примером реализации подобного если такова имеется.

UPDATE. И еще вопрос, тогда же опять таки нужно при каждом выполнении страницы считывать данные из файла? Это не будет грузить сайт?

(Отредактировано автором: 28 Января, 2015 - 17:53:06)

 
 Top
esterio
Отправлено: 28 Января, 2015 - 18:04:16
Post Id



Активный участник


Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012  
Откуда: Украина, Львов


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

Тянуть с файла все равно бистрее подсчета
 
 Top
GoDr
Отправлено: 28 Января, 2015 - 18:22:03
Post Id



Посетитель


Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015  
Откуда: Тамбов


Помог: 17 раз(а)
да о чём вы вообще говорите?????? Это МАГАЗИН!!!! Да там при открытии главной страницы будет дай бог минимум сотня запросов! И не просто безобидный запрос
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT COUNT (`id`) FROM `user`

а очень даже мощные... Глупо взять с собой на борт Боинга канистру керосина Радость
(Добавление)
.
Кстати Хорошо
Цитата:
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.

(Отредактировано автором: 28 Января, 2015 - 18:24:47)



-----
Система управления веб-содержимым Lotos CMS
 
 Top
skiphog
Отправлено: 28 Января, 2015 - 18:42:11
Post Id



Частый гость


Покинул форум
Сообщений всего: 139
Дата рег-ции: Дек. 2014  
Откуда: Киров, Россия


Помог: 11 раз(а)
GoDr пишет:
да о чём вы вообще говорите??????

Ну хочется человеку поиграться, пусть поиграется Улыбка
--
SWORDMAN погуглите по кешированию - информации много.

--
Вот самый простой пример Радость
PHP:
скопировать код в буфер обмена
  1. <?PHP
  2. //проверяете существует ли файл с кешем.
  3. if(!is_file('cache.php')) {
  4.   //Если файла нет, то подключаетесь к БД, достаете данные, делаете с ними всякую всяку
  5.   $arr = array();
  6.   for($i = 0;$i < 100;$i++) {
  7.     $arr[] = uniqid();
  8.   }
  9.   //Включаем буферицазию
  10.   ob_start();
  11. ?>
  12.   <h1>Привет мир</h1>
  13.   <section>
  14.     <p>Эти данные пришли из БД, сфоримрованные очень тяжелым запросом и пропущеные через 100 функций</p>
  15.     <ul>
  16.     <?PHP
  17.       foreach($arr as $value) {
  18.         echo '<li>', $value,'</li>',"\n";
  19.       }
  20.     ?>
  21.     </ul>
  22.   </section>
  23. <?PHP
  24.   //получаем содержимое буфера
  25.   $cache = ob_get_clean();
  26.   //сохраняем в файл
  27.   file_put_contents('cache.php',$cache);
  28. }
  29. //выводим файл или в переменную запишите, как хотите ...
  30. readfile('cache.php');
  31.  
  32. // А потом в обработчике, где происходит регистрация, после успешной регистрации удалите кеш-файл
  33. /*
  34. if(is_file('cache.php')) {
  35.   unlink('cache.php');
  36. }
  37. */

P.S. GoDr select count(*) быстрее, чем select count(`id`) Язычок

(Отредактировано автором: 28 Января, 2015 - 18:57:19)

 
My status
 Top
GoDr
Отправлено: 28 Января, 2015 - 18:55:53
Post Id



Посетитель


Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015  
Откуда: Тамбов


Помог: 17 раз(а)
skiphog пишет:
P.S. GoDr select count(*) быстрее, чем select count(`id`)
Знаю. Специально указал ID, чтобы визуально показать что считаем Радость
(Добавление)
.
PS
если нет WHERE


-----
Система управления веб-содержимым Lotos CMS
 
 Top
Мелкий Супермодератор
Отправлено: 28 Января, 2015 - 19:10:54
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)
GoDr пишет:
И не просто безобидный запрос

Ой далеко не безобидный.
Читать xmin/xmax каждой записи для текущей транзакции, чтобы узнать, существует ли эта запись.
На моём стенде сейчас никчёмные 400к записей считаются аж 0,1с (без query cache, но данные уже прогреты).
Да в такое время джойн на пяток таблиц впихнуть запросто можно.


-----
PostgreSQL DBA
 
 Top
GoDr
Отправлено: 28 Января, 2015 - 19:27:58
Post Id



Посетитель


Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015  
Откуда: Тамбов


Помог: 17 раз(а)
ну уж не знаю что читать Язычок
Чистый запрос без каких либо условий, судя по документации очень даже оптимизирован...


-----
Система управления веб-содержимым Lotos CMS
 
 Top
Мелкий Супермодератор
Отправлено: 28 Января, 2015 - 19:40:15
Post Id



Активный участник


Покинул форум
Сообщений всего: 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
 
 Top
GoDr
Отправлено: 28 Января, 2015 - 20:55:16
Post Id



Посетитель


Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015  
Откуда: Тамбов


Помог: 17 раз(а)
Мелкий, ну понятно что при условии.......... Язычок
И я не знаю от куда у тебе такие данные, но вот сейчас сделал пробную табличку 150000 записей

Если MyISAM, то
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT COUNT(*) FROM tbl1;
  2. /* Affected rows: 0  Найденные строки: 1  Предупреждения: 0  Длительность  1 query: 0,000 sec. */
  3.  


Если InnoDB, то
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT COUNT(*) FROM tbl1;
  2. /* Affected rows: 0  Найденные строки: 1  Предупреждения: 0  Длительность  1 query: 0,032 sec. */

(Добавление)
.
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

(Добавление)
наверное нужно миллиона три сделать и проверить.. но уж слишком долго забивать запросы... Улыбка

(Отредактировано автором: 28 Января, 2015 - 21:10:45)



-----
Система управления веб-содержимым Lotos CMS
 
 Top
Мелкий Супермодератор
Отправлено: 28 Января, 2015 - 21:16:30
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)
GoDr пишет:
от куда у тебе такие данные

GoDr пишет:
query: 0,032 sec.

400к записей / 150к записей * 0.032с = 0,085с.
Собственно, ещё 15мс можно принять за разницу железа и вот они, 0,1с чистого count.

GoDr пишет:
не могу повторить такой результат: не даёт больше 0,001 sec

Мелкий пишет:
(без query cache, но данные уже прогреты).

CODE (SQL):
скопировать код в буфер обмена
  1. SELECT SQL_NO_CACHE COUNT(*) FROM tbl1;


-----
PostgreSQL DBA
 
 Top
GoDr
Отправлено: 28 Января, 2015 - 21:21:08
Post Id



Посетитель


Покинул форум
Сообщений всего: 446
Дата рег-ции: Янв. 2015  
Откуда: Тамбов


Помог: 17 раз(а)
да уж....
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT SQL_NO_CACHE COUNT(*) FROM tbl1;
  2. /* Affected rows: 0  Найденные строки: 1  Предупреждения: 0  Длительность  1 query: 0,015 sec. */

видимо что-то первый раз не то было...

А с MyISAM даже не могу получить одну тысячную секунды
(Добавление)
хотя с другой стороны... 400000 зарегистрированных пользователей - можно только позавидовать такому сайту Закатив глазки

Да и само число пользователей с сервера клиенту будет идти дольше ))))) А если ещё если представить в одном запросе 5-7 JOIN, эти циферки покажутся смешными...

(Отредактировано автором: 28 Января, 2015 - 21:29:34)



-----
Система управления веб-содержимым Lotos CMS
 
 Top
Мелкий Супермодератор
Отправлено: 28 Января, 2015 - 22:13:51
Post Id



Активный участник


Покинул форум
Сообщений всего: 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)

mysql> show profiles;
+----------+-------------+------------------------------------------------+
| Query_ID | Duration | Query |
+----------+-------------+------------------------------------------------+
| 1 | 0.10843100 | SELECT SQL_NO_CACHE count(*) FROM `works_task` |
| 2 | 0.00008600 | select version() |
| 3 | 0.05099200 | SELECT DATABASE() |
| 4 | 0.00008500 | SELECT DATABASE() |
| 5 | 0.00021100 | show databases |
| 6 | 0.00010900 | show tables |
| 7 | 10.78341200 | select SQL_NO_CACHE count(*) from brt_rating |
+----------+-------------+------------------------------------------------+
7 rows in set (0.00 sec)

mysql> show profile for query 7;
+--------------------+-----------+
| Status | Duration |
+--------------------+-----------+
| starting | 0.000046 |
| Opening tables | 0.000009 |
| System lock | 0.000003 |
| Table lock | 0.000006 |
| init | 0.000009 |
| optimizing | 0.000004 |
| statistics | 0.000007 |
| preparing | 0.000006 |
| executing | 0.000004 |
| Sending data | 10.783152 |
| end | 0.000008 |
| query end | 0.000003 |
| freeing items | 0.000148 |
| logging slow query | 0.000003 |
| logging slow query | 0.000002 |
| cleaning up | 0.000002 |
+--------------------+-----------+
16 rows in set (0.00 sec)

Это уже прогретые данные, ага

GoDr пишет:
хотя с другой стороны... 400000 зарегистрированных пользователей - можно только позавидовать такому сайту

С этим не спорю.

GoDr пишет:
если ещё если представить в одном запросе 5-7 JOIN, эти циферки покажутся смешными...

CODE (SQL):
скопировать код в буфер обмена
  1. SELECT SQL_NO_CACHE `comp_id`,`project_id`,`work_id`,`search_param_id`,`keyword_id`,`site_url`,`keyword`,`search_param`
  2. FROM `works_task`
  3. JOIN `works` USING (`comp_id`,`project_id`,`work_id`)
  4. JOIN `projects` USING (`comp_id`,`project_id`)
  5. JOIN `keywords` USING (`comp_id`,`keyword_id`,`project_id`)
  6. JOIN `searchparams` USING (`comp_id`,`project_id`,`search_param_id`)
  7. WHERE `search_maschine_id`=1 AND `progress`=0 AND `projects`.`is_deleted`=0
  8. ORDER BY `priority`,`start`,`keyword_id`
  9. LIMIT 10

Достаточно внушительно? Подмигивание
works_task - та самая табличка на 400к записей, весь этот запрос около 0.04398800с
Цитата:
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000074 |
| Opening tables | 0.000015 |
| System lock | 0.000005 |
| Table lock | 0.000006 |
| init | 0.000076 |
| optimizing | 0.000020 |
| statistics | 0.000122 |
| preparing | 0.000026 |
| Creating tmp table | 0.000024 |
| executing | 0.000002 |
| Copying to tmp table | 0.037967 |
| Sorting result | 0.001446 |
| Sending data | 0.000056 |
| end | 0.000003 |
| removing tmp table | 0.003796 |
| end | 0.000004 |
| query end | 0.000003 |
| freeing items | 0.000335 |
| logging slow query | 0.000004 |
| cleaning up | 0.000004 |
+----------------------+----------+

Больше чем в два раза быстрее "простого" count только по одной таблице из объединения.


-----
PostgreSQL DBA
 
 Top
Поиск в теме | Версия для печати
Страниц (2): [1] 2 »
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« Вопросы новичков »


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



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB