Карта сайта для ботов - phpBB3 SEO Sitemap

[Пчелкин]

говнохостингом всё будет ещё печальнее

+100 ... Полностью согласен... за 650 р на год хост хорошим не бывает... И сидим мы потом и выбираем в опциях чего б им еще отключить чтоб снизить тааааам еще что...А им подавай и спасибки, и медальки, и СЕО и еще черт знает чего...Даж СП подавай на 4 гега винта, 256 мозгов и селероне в 0,750... Даж такое было... Поэтому согласен с Shredder - какой на хрен крон... Все и так пучком...

[xisp]

Поэтому я сейчас думаю над механизмом, который позволит сделать "правильное время модификации" без увеличения числа запросов

Да ничто не мешает сбагрить всё одним запросом. Я даже замерял- выполняется за обычное время, меньше сотой секунды. Но тогда повысится нагрузка со стороны PHP, разгребать массив ответа на мегабайты. Хотя может я и зря за него волнуюсь. Потестирую- выложу принцип действия. В моём механизме учитывается так же время изменения поста, если оно больше времени модификации последнего сообщения- то время модификации страницы будет именно им.

[Shredder]

В моём механизме учитывается так же время изменения поста, если оно больше времени модификации последнего сообщения- то время модификации страницы будет именно им.

Это - само собой, я планировал сделать так же. Проблема только ещё в том, что по умолчанию время модификации не обновляется при правке модерами и админами.

[xisp]

Проблема только ещё в том, что по умолчанию время модификации не обновляется при правке модерами и админами.

Меня это тоже смутило. Уже хотел ставить мод, который обязательно ставит отметку "Редактировалось тогда-то", и, соответственно, прописывает время редактирования в БД.
Я не копал движок на этот счёт, но нельзя ли отвязать метку о редактировании от записи времени в БД? ИМХО, время правки нужно писать всегда.

[Shredder]

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

Меня это тоже смутило. Уже хотел ставить мод, который обязательно ставит отметку "Редактировалось тогда-то", и, соответственно, прописывает время редактирования в БД.

Ага, и при этом появляется надпись "сообщение редактировалось бла-бла-бла...", что может некоторых бесить. В общем, не вариант.

нельзя ли отвязать метку о редактировании от записи времени в БД? ИМХО, время правки нужно писать всегда.

Если имеется в виду, чтобы время писалось в БД, но в самом посте при этом не писалось, что он редактировался, то тем или иным способом это сделать можно. Либо отвязкой, либо добавлением нового поля.

[xisp]

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

Я так и сделал, хоть первое правь.

Либо отвязкой, либо добавлением нового поля.

Да, новое поле будет лучшим выходом. По умолчанию 0, отображать, а при редактировании новых в тех случаях, когда стандартный движок просто не писал время редактирования в БД, нужно записывать 1 в новое поле и само время. И текущие посты не сломаются, и новые нормально будут отображаться, так как иногда нужно видеть, когда сообщение кем- то правилось.

[Shredder]

Да, новое поле будет лучшим выходом.

Сегодня всё сделал. Всё оказалось гораздо проще, чем казалось в начале. Пока не выкладываю, т.к. требует окончательного тестирования с моей стороны, плюс оформления в виде MODX, и если возможно, создание такой же системы для страниц форумов. Но факт, что способ работает без видимых отклонений - уже установлен.
Запросов, по-прежнему, 2, отличие теперь только в том, что в цикле проверяются не все темы, а все посты. Соответственно, нагрузка может возрасти. А вот насколько - вопрос серверных тестов. Буду думать, как и где их провести.

[Shredder]

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

[xisp]

если создаётся новая тема, то все остальные темы сдвигаются вниз на всех страницах форума,

Чаще отвечают в существующих, но да, примерно так.
Жду нового релиза, сравню эффективность алгоритмов.

[Shredder]

Замерил скорость выполнения скриптов до и после "усовершенствования", тест проводился на форуме с 6666 URL. Результат: 0,6 с. против 4,2. Т.е., стало больше в 7 раз. Это без кеша. С кешем будет 0,05 с, но про кеш речь и не идёт. Как по мне, результат неудовлетворительный. Овчинка выделки не стоит.

[Обновлено 23.03.2014]
Полученные выше данные оказались ошибочными, см. этот пост - Карта сайта для ботов - phpBB3 SEO Sitemap

[xisp]

Результат: 0,6 с. против 4,2. Т.е., стало больше в 7 раз.

Господи, 5 секунд в сутки.

Прикрепил файлы в архиве, если кто-то захочет проверить сие "чудо".

А я массив целиком сортировал, и выбирал первый элемент //_-)

А, нет, сортировать массив и выбирать первое значение оказывается чуть быстрее вызова max, совсем чуть- чуть. Или у меня глюки

[Пчелкин]

Хм... Не знаю почему и что и как, но, думаю, первые итоги работы карты -
1. Появились четыре новые поисковые машины (боты) на форуме. В списках ботов были давно. Но никогда не являлись...Явились...
2. Падение гугловского индекса приостановилось... надолго ли - вопрос
забыл еще:
3. Алексовский индекс полез вверх (наконец-то, семь месяцев падал или почти стоял на месте, даж не смотря на бурное добавление контекта)

[Shredder]

А, нет, сортировать массив и выбирать первое значение оказывается чуть быстрее вызова max, совсем чуть- чуть. Или у меня глюки

Выполнение max там занимает около 0,1 (одной десятой) секунды, т.е. не играет никакой роли. Основной упор идёт именно на перебор постов. Если оставить даже вот такой элементарный код:

Код: Выделить всё

	$sql = 'SELECT t.topic_id' . $add_sql . ', t.topic_type, t.topic_last_post_id, t.forum_id, p.post_id, p.post_time, p.post_modified
		FROM ' . TOPICS_TABLE . ' t, ' . POSTS_TABLE . ' p
			WHERE t.topic_approved = 1 AND t.topic_status <> ' . ITEM_MOVED . ' AND t.topic_id = p.topic_id
		ORDER BY t.topic_id, p.post_time ASC';
	$result = $db->sql_query($sql);

	$times = array();
	$per = $config['posts_per_page'];
	$page = $post = 0;

	while ($data = $db->sql_fetchrow($result))
	{
		$f_id = (int) $data['forum_id'];
		$t_type = (int) $data['topic_type'];

		if ($t_type == POST_GLOBAL || ($auth->acl_get('f_list', $f_id) && !in_array($f_id, $excl)))
		{
			$times[] = $data['post_time'];
		}
	}

То время выполнения всё ещё будет 3,6 с. Можно даже $times[] = $data['post_time']; убрать - ничего не изменится всё равно.

И это на хорошем хостинге и на форуме со 120 тысячами постов. Что будет с несколькими миллионами постов - можно только гадать.

[xisp]

А что делает вот этот код:

Код: Выделить всё

if ($t_type == POST_GLOBAL || ($auth->acl_get('f_list', $f_id) && !in_array($f_id, $excl)))

По моему проверять права нужно на разделы, права на темы и посты всё равно не выдать. Именно эта проверка прав на каждый пост съедает всё время.

Вот как было сделано мной на основе sitemap_fx, код из цикла перебора топиков:

Код: Выделить всё

		$sql = 'SELECT post_time, post_edit_time
			FROM ' . POSTS_TABLE . '
				WHERE topic_id = ' . $row['topic_id'];
		$res = $db->sql_query($sql);

		$row_time_page = $row_time_post = array();

		while ($rows = $db->sql_fetchrow($res))
		{
				$row_time_post[] = max($rows['post_time'], $rows['post_edit_time']);
		}
		$db->sql_freeresult($res);

		$row_time_page = array_chunk($row_time_post, $config['posts_per_page']);

		$pages = $row['topic_replies'] / $config['posts_per_page'];
		$pages = (int) $pages;

		for ($i=0; $i<=$pages; $i++)
		{
			rsort($row_time_page[$i]);
			$last_mod = $row_time_page[$i][0];

Дальше идёт формирование самой карты.
Проверка прав осуществляется на уровне разделов.
Запрос в цикле, число запросов равно числу топиков, но никто не умер что на лоалхосте, что на шареде.
Да и запрос у вас сложноват для БД, но это ИМХО, ибо я нуб в этом.
Для раздела с 4000 постов обще время заполнения составило 0,055523157119751.

[Shredder]

Проверка ничего почти не съедает. Максимум - полсекунды. Убери её хоть вообще, будет почти то же самое. Нужно для проверки прав чтения форума и исключения форумов из списка исключений. Я уже проверял и не раз - основное время съедает именно перебор сам по себе, в его чистом виде. Вот если бы запрос ещё как-то усложнить, чтобы не приходилось в цикле потом столько значений переваривать, а вместо этого он сам бы выбирал максимальное значение времени для каждой страницы, то может быть, что-то бы и получилось. Но я не мастер MySQL и составления супер-сложных запросов, так что вряд ли что-то придумаю тут. Если, конечно, это вообще возможно.

Добавлено спустя 2 минуты 48 секунд:

Для раздела с 4000 постов обще время заполнения составило 0,055523157119751.

А каким образом считаешь время?