Глюки и баги www.uz

[Максуд Нишанов]

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

[JackDaniels]

Сообщение от Максуд Нишанов

запросы начинают зависать в процессах БД и запрос на выполнение было отклонено через некоторое время.

Максуд, конечно, всегда есть какой-то процент сбоев и ошибок, но то, что твориться с Рейтингом, уже ни в какие ворота…
Он попросту часто недостоверен.

Можно же увеличить производительность БД, не прибегая к радикальным мерам, типа смены железа, ведь практически всегда найдется что-то поддающееся оптимизации.

Вот например, страница: http://www.uz/ru/catalogue/ генерируется около 2 секунд, явно же, что либо запросы не оптимизированы, или индексы в БД выставлены не корректно.
То же и со страницей: http://www.uz/ru/catalogue/toprating/ (можно пойти и в сторону экономии ресурсов, выдавать в Топ-Рейтинге не 60, а 30 результатов на страницу, хотя, страничка примитивная, и должна открываться за доли секунды).

Поймите правильно, я ни чуть не придираюсь, но это ведь не просто счетчик посещений коих миллионы, а рейтинг WWW.UZ.

[Sparc]

Сообщение от Руслан Худяков

Он попросту часто недостоверен

Вот еще один баг, неправильный подсчет хостов и хитов за прошлую и эту неделю
https://img.uforum.uz/images/drntatr9753994.jpg

[Максуд Нишанов]

Сообщение от Sparc

Вот еще один баг, неправильный подсчет хостов и хитов за прошлую и эту неделю https://img.uforum.uz/images/drntatr9753994.jpg

Уважаемый Sparc!
Если бы Вы указали названия ресурса, тут думаю многие были бы благодарны. Так как Вы урезали из скриншота основную информацию о ресурса, я принимаю это за аноним. Но всё таки, поясняю еще раз, с 07 января 2012 года Все данные идущие со счётчиков 100% записываются в БД и все статистики которые отображаются на страницах www.uz основаны на этих записей.

[JackDaniels]

Сообщение от Максуд Нишанов

с 07 января 2012 года Все данные идущие со счётчиков 100% записываются в БД и все статистики которые отображаются на страницах www.uz основаны на этих записей.

Вынесу отдельно: За всю прошлую неделю показывает всего 3 155 985 хитов, уже на глюк похоже?

— Сводная статистика

[Sparc]

Сообщение от Максуд Нишанов

Уважаемый Sparc!
Если бы Вы указали названия ресурса, тут думаю многие были бы благодарны. Так как Вы урезали из скриншота основную информацию о ресурса, я принимаю это за аноним. Но всё таки, поясняю еще раз, с 07 января 2012 года Все данные идущие со счётчиков 100% записываются в БД и все статистики которые отображаются на страницах www.uz основаны на этих записей.

Уважаемый Максуд Нишанов!
Название ресурса определить не представляет большого труда, достаточно в топ-рейтинге за сегодня найти ресурс под порядковым номером 276 (в скриншоте эта часть хорошо видна).

Насчет "правильной" статистики ресурса за прошлую неделю достаточно посмотреть статистику за прошлую неделю по дням.

[Максуд Нишанов]

Сообщение от Руслан Худяков

Максуд, конечно, всегда есть какой-то процент сбоев и ошибок, но то, что твориться с Рейтингом, уже ни в какие ворота… Он попросту часто недостоверен. Можно же увеличить производительность БД, не прибегая к радикальным мерам, типа смены железа, ведь практически всегда найдется что-то поддающееся оптимизации. Вот например, страница: http://www.uz/ru/catalogue/ генерируется около 2 секунд, явно же, что либо запросы не оптимизированы, или индексы в БД выставлены не корректно. То же и со страницей: http://www.uz/ru/catalogue/toprating/ (можно пойти и в сторону экономии ресурсов, выдавать в Топ-Рейтинге не 60, а 30 результатов на страницу, хотя, страничка примитивная, и должна открываться за доли секунды). Поймите правильно, я ни чуть не придираюсь, но это ведь не просто счетчик посещений коих миллионы, а рейтинг WWW.UZ.

Уважаемый Руслан Худяков!
Спасибо за Ваше мнение. На данный момент мы добились чтобы www.uz больше не выдавал ошибку "Сервер перегружен", при постоянно растущих запросах в течение сутки. На стороне сервера работает куча обслуживающих скрипт-демонов, чтобы обеспечить работу проекта. Впереди еще много работ, начиная от реструктуризации БД, оптимизации запросов (а это делается постоянно) до кластеризации БД, служащей проекту.

Сообщение от Руслан Худяков

что твориться с Рейтингом, уже ни в какие ворота… Он попросту часто недостоверен.

Почему так думаете? Я не согласен с Вашем мнением по части что Рейтинг недостоверен. Все поступающие данные от наших счётчиков обрабатываются 100 % вовремя, также мы предотвратили утери данных посыламых от наших счётчиков при зависании БД. Т.е., если страница, где установлена наш счётчик догрузилась до конца, данные посетителя 100% записывается в БД.

Конечно, я еще не удовлетворен своей работой над этим проектом, у нас впереди много планов, и в первую очередь это довести данный имеющийся функционал сайта до ума.

[JackDaniels]

Сообщение от Максуд Нишанов

Почему так думаете? Я не согласен с Вашем мнением по части что Рейтинг недостоверен.

Я не думаю, это очевидно из вышесказанного в этой теме.
В частности

Сообщение от Sparc

Вот еще один баг, неправильный подсчет хостов и хитов за прошлую и эту неделю
https://img.uforum.uz/images/drntatr9753994.jpg

Вообще, в Рейтинге 1506 сайтов, то есть в таблице БД 1506 записей, а это практически ничто для MySQL.
Согласно Сводной статистики за вчерашний день было 3 719 285 хитов, то есть именно столько раз счетчики обратились к www.uz, а это всего около 36 запросов в секунду.
(кстати, за всю прошлую неделю показывает всего 3 155 985 хитов, уже на глюк похоже?)

Подобная таблица будет весить, ну пусть 10-15 Мбайт, всего лишь.
Просто я хочу сказать, что с таким объемом MySQL справляется запросто даже на простом Pent 4 и при том «летает».

Для примера, у меня есть достаточно нагруженный (причем далеко не самый мощный) сервер, с таблицей в 650 000 записей, и весом только этой таблицы более 180 Мбайт, простенький запрос "SELECT * FROM `tabtab` LIMIT 0 , 300" занимает 0.0078 сек, вытащить 30 тыщ элементов "SELECT * FROM `tabtab` LIMIT 0 , 30000" занимает 0.553 сек".
Естественно, что по мимо БД там крутится еще много чего, и не просто скрипты, а достаточно прожорливые демоны.

[Djalolatdin Rakhimov]

Сообщение от Руслан Худяков

Можно же увеличить производительность БД, не прибегая к радикальным мерам, типа смены железа, ведь практически всегда найдется что-то поддающееся оптимизации.

Да и мощности добавим. Но без оптимизации логики, очень уж большая нагрузка на железо. Поэтому работаем по всем фронтам.

[Djalolatdin Rakhimov]

Сообщение от Максуд Нишанов

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

[MOD]Цитируйте сообщения, на которые отвечаете![/MOD]