Модератору о работе сайта!

Прошла неделя после изменений правил в клубе, очень печально, но работа сайта стала ещё хуже. В течении всей недели страницы открываются очень медленно, это хорошо если ещё открываются, а то и вообще зависают или страницу не находит. Притом ранее по вечерам и ночью было всё отлично, но на этой неделе и по ночам проблеммы :(
Кстати за эту неделю людей на сайте присутствовало меньше, чем на предыдущей. Эту проблемму надо как-то решать. Я не знаю как было раньше, но в сентябре и октябре прошлого года сайт работал превосходно, хотя количество фотографий в день было тоже как и сейчас.
Будет очень досадно если люди будут покидать сайт по причине, что сайт не работает нормально.

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

Я тоже еще вчера хотел написать по этому поводу, но не хватило времени. Смотреть фотографии стало совсем невозможно. Чтобы дождаться открытия страницы проходит от 10 сек до нескольких минут.
В свое время я писал Модератору об архитектуре сайта, и насколько важно разработать правильный каркас для сайта, где учтены все базовые особенности фотоклуба, нормализацию базы данных, использование процедур и индексов. Но к моему посту Модератор серьезно не отнесся.
По тому, как работают ссылки на сайте и как влияет нажатие определенной ссылки на время загрузки страницы можно сделать выводы, что основная проблема SQL запросах. В свое время во время ошибок появлялся текст SQL запроса. С учетом, что я увидел сделаю некоторые предложения, которые могут повлиять на скорость:
1. Использование JOIN для таблиц не желательно. Лучше в SQL запросах работать через primary - foreign ключи, особенно если таблиц больше двух.
2. Все обращения к базе данных должны работать через stored procedures. Так как они кэшируются в базе данных скорость выполнения запросов может возрасти в несколько раз или даже на порядки.
3. SQL запросы должны возвращать только необходимую информацию (не должно быть, что запрос возвращает 100 записей, а страница отображает только 15), все ограничения должны работать на стороне базы данных.

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

Цитата:

от: Александр Грабко

1. Использование JOIN для таблиц не желательно. Лучше в SQL запросах работать через primary - foreign ключи, особенно если таблиц больше двух.

Таблиц больше двух в запросе у нас крайняя редкость, в галерее и форумах такого нет.


Цитата:

от: Александр Грабко
2. Все обращения к базе данных должны работать через stored procedures. Так как они кэшируются в базе данных скорость выполнения запросов может возрасти в несколько раз или даже на порядки.

Вы предлагаете множество запросов для одной страницы выносить в отдельную процедуру? Страница с фотографией использует разные запросы и алгоритмы в зависимости от пользовательских настроек, авторских настроек, порядка и ключа сортировки для ссылок вперед-назад. На странице с фотографией работают около 15-20 запросов, но почти все запросы с cost = 0..50

Цитата:

от:Александр Грабко
3. SQL запросы должны возвращать только необходимую информацию (не должно быть, что запрос возвращает 100 записей, а страница отображает только 15), все ограничения должны работать на стороне базы данных.

Подробнее

Есть проблема - конструкция offset, но обойти это можно только если сортировка делается по редкоменяющемуся полю, самое простое по primary key. А вот как избавится от offset если сортировка по last_post_time - оно меняется постоянно.

SELECT
id,
title,
.....
last_post_time
FROM
forum.topics
WHERE
forum_id=3
ORDER BY
forum_id DESC, last_post_time DESC
LIMIT 20 OFFSET 300
Limit (cost=734.60..783.57 rows=20 width=123)
-> Index Scan Backward using topics_forum_id_last_post_time on topics (cost=0.00..5806.78 rows=2371 width=123)
Index Cond: (forum_id = 3)


Очевидная борьба с оффсетами - группировка постов, фоток и комментов по кластерам, скажем посуточно-месячно-недельно, как на форуме авто.ру. Но отменять сквозной просмотр фотографий или топиков жалко.

Вообще, если хотите помочь - пишите, пожалуйста, мне на volod@volod.ru - лишних специалистов по БД у нас никогда не было :(

База postgresql, 7.4

Цитата:

от: Volod

Вообще, если хотите помочь - пишите, пожалуйста, мне на volod@volod.ru - лишних специалистов по БД у нас никогда не было :(

Написал Вам на Email варианты решения проблемы ...

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