Я Red Khan'у задал тут один интересный вопрос, но ответа у него не оказалось. Спрашиваю просто так, если что.
Цитата: ЯХан, я Вас как модератора хочу спросить. Каков максимальный размер темы на ЛФ? Нет никаких ограничений? Посмотрите на переводы с/на узбекский. Там уже 306 стр.! Не пора ли закрывать тему и создавать новую? Мнаше, помнится, закрывал популярные бредотемы вроде Цитат или Чё меня бесит, когда там более 200 стр. набиралось. Как Вы думаете?
Кажется, точного ответа на вопрос (после какого размера нагрузка на сервер ощутимо растёт) не знает никто, но мне так помнится, что старались не превышать 200 страниц, вот я примерно на это и ориентируюсь.
RawonaM поправит, если что...
Технических ограничений вроде как не выставленно. Вроде была такая настройка.
Наверное стоит поставить 5000 сообщений, просто для разгрузки базы данных.
А почему база грузится при большом количестве сообщений в одной теме?
Размер таблицы ограничен.
Размер таблицы ограничен? :O
А что, на каждую тему создаётся таблица? :O
Цитата: Тайльнемер от ноября 28, 2013, 03:29Размер таблицы ограничен? :O
На платном сервере — наверняка. Не программно, естественно.
Bhudh, да что вы.
Во-первых, вряд ли размер таблицы в БД ограничен, тем более таким маленьким числом.
Во-вторых, если бы размер темы был ограничен, новые сообщения бы просто не посылались. А здесь речь о повышении нагрузки на сервер.
В-третьих, крайне маловероятно, что на каждую тему отводится таблица. Скорее, есть одна таблица, в которой помещаются все сообщения всех тем (недаром у них сквозная нумерация), и, наверное, есть таблица соответствия № темы ↔ № сообщения.
Т. е. для показа страницы темы нужно из всех сообщений, соответствующих теме (они вытаскиваются быстро засчёт индексации) пропустить количество, соответствующее предыдущим страницам и вытащить количество сообщений на странице. Вот, видимо, этот пропуск и тормозит, когда страниц много.
SELECT [Messages].[Id], [Messages].[AuthorId], [Messages].[Text], . . .
FROM [Messages]
INNER JOIN [TopicMessages] ON [Messages].[Id] = [TopicMessages].[MessageId]
WHERE [TopicMessages].[TopicId] = @topicId
OFFSET @messagesPerPage * (@page - 1) ROWS
FETCH NEXT @messagesPerPage ROWS ONLY;
Цитата: Тайльнемер от ноября 28, 2013, 06:34пропустить количество, соответствующее предыдущим страницам и вытащить количество сообщений на странице. Вот, видимо, этот пропуск и тормозит
Скорее, не сам пропуск, а вычисление необходимых для пропуска страниц, число которых меняется настройкой числа постов на странице у конкретного юзера.
Цитата: Тайльнемер от ноября 28, 2013, 06:34@messagesPerPage
А это нагрузка не на базу данных, а на процессор.
Цитата: Bhudh от ноября 28, 2013, 06:55
Скорее, не сам пропуск, а вычисление необходимых для пропуска страниц
Причём здесь вычисление — однократное арифметическое действие?
Вот пропуск требует перебора — он выполняется за O(page).
Цитата: Тайльнемер от ноября 27, 2013, 04:36
А почему база грузится при большом количестве сообщений в одной теме?
Не вдавался в подробности, но во всех списках оптимизации это присутствует, например:
http://www.simplemachines.org/community/index.php?topic=293441.0
ЦитироватьAddition #3 (July 1st): Cap the length of your threads This is one of those things that ought to be a setting - even vBulletin is known for choking on large threads, look up rpg.net's motivational poster history. Large threads mean there is a large result set for further instructions in the query to prune from, and if a thread is too disproportionally large, even browsing the thread will result in using table scans instead of the index - a very bad situation indeed.