|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Собственно тема состоит из одного вопроса, что было бы лучше один запрос в какую-то отдельную таблицу со всеми статистическими данными по пользователям или с 15 COUNT по нормально проиндексованным таблицам в базы к разным модулям. Например сколько у человека фоток загружено, сколько друзей, в дневнике сообщений и т.п. то есть исключительно подсчет количества строк в каких то побочных таблицах. Переделка кучи COUNT даст значительный прирост или игра не стоит свеч?
Сейчас на самой "крутой" пользовательской странице где стоят все модули: Страница генерировалась 0.14796 секунд и было совершено 40 запросов к БД
Среднее время генерации именно личных страниц самое высокое по сайту, отдельные модули работают быстрее в десятки раз.
Я и сам склоняюсь к сие "модернизации", но что-то терзают меня сомнения...
Заранее спасибо за любой ответ.
Неактивен
Важно понять что именно происходит наиболее медленно при загрузке страницы профиля и насколько именно страница профиля нагружает сервер (у учетом ее популярности). Уберите вообще все COUNT(), будет ли разница в производительности заметна для сервера?
Неактивен
Как интерестно получилось......
Выйгрыш получился процентов 10-20%. И то как-то размыто. А как замерить все запросы? Просто тупо сидеть и все 40 запросов в phpmyadmin'e вставлять?
Неужели нету какого-то дебагера, который бы сравнил запросы и показал хотя бы примерно на "узкие места".
Отредактированно Proger (28.01.2009 16:49:06)
Неактивен
Ради 10-20% не стоит заморачиваться усложнением структуры данных. Проще арендовать более мощный сервер.
Есть только сторонние продукты, например, MySQL Proxy
Неактивен
хм. ну я вот нашел пару мест где в COUNT цепляет не тот индекс. Непонятно почему, запрос типа SELECT COUNT(*) FROM table WHERE id1 = 1 а он цепляет не индекс где одно поле id1 а индекс полей id1 и id2 0_0
А вообще время запроса можно средствами php наверное замерить, взяв микротаймштамп до команды mysql_query и после? Это будет более менее верно?
Да ещё тут подумал в каждом модуле сделать тоже подсчеты сколько какой модуль проработал, может это покажет нагруженное место. Что-то сразу не додумался. Может и в самом приложении где узкое место.
Отредактированно Proger (28.01.2009 16:57:39)
Неактивен
Если можно взять несколько индексов, он бере первый попавшийся. Используйте FORCE INDEX(id1)
Можно в PHP измерить. Но тут еще важно, что профиль это, например, 5% обращений к сайту и ускорение на 20%. В общей произвоидительности выйгрыш 1%.
Неактивен
К сожалению в соц. сетях профиль это 20% обращений если не больше. Первым делом люди заходят на личную страницу, посещают страницы друзей.
Спасибо за FORCE INDEX. Будем думать. Спасибо!!!
Неактивен
В таком случае стоит кешировать выписку о человеке целиком. Так реализовано, например, в форуме vbulletin - кешируются распарсенные подписи, аватары и.т.д.
Неактивен
Хм, тоже интерестная штука. Очень даже. Ещё один повод для размышлений.
Неактивен
Возник тут попутный, так сказать, вопрос.
А кешировать лучше всё и вся, то есть уже готовый HTML код или всё таки данные? или тут от случая к случую нужно выбирать и лучше не переусердствовать с количеством данных?
Неактивен
В vbulleting кэшируется распарсенный html-код, например, для подписи. В общем. универсального рецепта нет, так как возможности зависят от специфики задачи.
Неактивен
Ну есть какие то рекомендации по количеству сохраняемой информации. Например не более 100 КБ на SQL запись. Или это абсолютно неважно? Просто хочется понять, где порог эффективной оптимизации. То есть когда польза есть от кеша и когда уже кеш перерастет по нагрузкам текущее приложение без кеша. Хотя конечно, наверное, это врятли получится, ибо по идее независимо от количество хранимых данных в кеш-таблице кеш всегда будет срабатывать быстрее. Хотя может и не так.
И тогда вопрос в догонку какой лучше брать тип таблиц для кеша (MyISAM, MEMORY, InnoDB).
Я лично придумал так, что пользователь скажем первый раз зашел на свою страницу сгенерировался скажем даже за 0.5 сек полный HTML код страницы (так как кеши MySQL тоже не отрабатывают при первом запросе) и я этот код сохраняю в таблицу cachemember скажем. Как только пользователь, что либо изменит и соответственно изменится его страница, мы удаляем запись в кеше и создаём новую.
Обновлять информацию в кеше, как я понял, неразумно если таблица MyISAM. MEMORY будет выжирать память, коей немного 512 МБ. Наверное самое разумное InnoDB будет тут.
Неактивен
Хм. Замерил скорости генерации с кешем. Получил прирост от 3-4 раз в отдельных случаях (когда сервер не нагружен) до 10. Вот только понять бы какой тип таблиц под кеш пускать. Как мне представляется проще данные не менять в кеше, а удалять и генерировать заново, ибо там готовый html уже и искать нужные места для изменения тяжко, только если регулярными выражениями и поставить какие-то метки/якоря.
Отредактированно Proger (02.02.2009 20:38:41)
Неактивен
Если нет блобов, то купить память и сделать таблицы MEMORY. Если есть блобы, то, наверное, Innodb. Записи кэша только создавать и удалять, обновлять нет смысла. В остальном оптимизация - чисто практическое дело.
Неактивен
Блобов не имеем. Идею понял. Реализуем потихоньку - мне нравиться.
Спасибо - всегда очень помогаете.
Неактивен
Страниц: 1
