Юрий Синодов ([info]sinodov) wrote,
2009-01-08 12:12:00
  • Previous
  • Memorize
  • Share
  • Next

Пятая серия

Запрос, который был озвучен в первой серии, применялся для формирования блока "недавние комментарии", насколько я понял. Поскольку подпорка под него не сработала (читайте четвертую серию) блок пока убрали полностью.

Обновляется блок этих комментариев раз 200-300 в сутки, не больше - может просто его в статике сделать?

Думаем

первая серия
вторая
третья
четвертая

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    switch

    Your reply will be screened

     
    Help
  • 40 comments

[info]illyn

January 8 2009, 09:19:11 UTC 3 years ago

Ты имеешь в виду те что были справа внизу?

[info]sinodov

January 8 2009, 09:20:43 UTC 3 years ago

Да

[info]vol1oleg

January 8 2009, 09:21:45 UTC 3 years ago

Юр, вчера часа в три ночи синхронно:
http://pics.livejournal.com/pro_kuratora/pic/00010x03
http://pics.livejournal.com/pro_kuratora/pic/00011q63

[info]sinodov

January 8 2009, 09:22:51 UTC 3 years ago

Какое нафиг синхронно, мы уже сутки на тот момент практически в перманентном дауне были

[info]vol1oleg

January 8 2009, 10:27:11 UTC 3 years ago

Видимо, мне "счастливилось". Перешел с какой-то из ссылок Роема в ЖЖ. Потом ЖЖ упал - возвращаюсь на Роем, чтобы написать о падении, смотрю - оппаньки )

[info]illyn

3 years ago

  • Loading...

[info]smirnov

January 8 2009, 09:27:14 UTC 3 years ago

а кнопку на рсс комментариев оставить тоже нельзя было?

[info]sinodov

January 8 2009, 09:31:28 UTC 3 years ago

Они формируются также, так что пока нет.

[info]alexclear

January 8 2009, 09:41:53 UTC 3 years ago

Добавить в запрос условие ограничения по дате или выражение LIMIT - гораздо менее трудоемкая операция, разве нет?

[info]sinodov

January 8 2009, 09:49:08 UTC 3 years ago

Я кидал ссылку прогеру на все эти обсуждения - говорит что нет, полностью его ответ привести не могу, так как не понимаю его сути, а дословно воспроизвести - запоминалки не хватает

[info]alexclear

January 8 2009, 09:57:37 UTC 3 years ago

Угу
Тогда проще этот запрос вообще не выполнять, а последние комментарии хранить в отдельной структуре, сериализовать на диск, например, и апдейтить при появлении нового комментария. Оперативно удаляя старые при этом, конечно же.

[info]artem_kv

3 years ago

  • Loading...

[info]alexclear

3 years ago

  • Loading...

[info]leonov

January 8 2009, 11:28:57 UTC 3 years ago

Ну это сказки какие-то. Единственная отмазка, которая мне может прийти в голову - что результаты запроса используются в разных местах, и потому в php приходит вся свалка, которая потом разгребается в нескольких местах по-разному. Но это ж не повод.

[info]kukutz

3 years ago

  • Loading...

[info]tulaman

3 years ago

  • Loading...

[info]sply

3 years ago

  • Loading...

[info]alexclear

3 years ago

  • Loading...

[info]ex_advertize733

3 years ago

  • Loading...

[info]raa

3 years ago

  • Loading...

[info]sergik

3 years ago

  • Loading...

[info]artem_kv

January 8 2009, 09:54:20 UTC 3 years ago

к прошлым сериям куча народу написала, что не надо выгребать 30мб комментариев и их потом в php тискать. но складывается впечатление, что идея на вашей с программером стороне признания не получила. это так? :-))

[info]sinodov

January 8 2009, 10:08:31 UTC 3 years ago

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

[info]linker.ya.ru

3 years ago

  • Loading...

[info]justbulat

January 8 2009, 10:22:14 UTC 3 years ago

эээ, незнаю начёт вашего sql-сервера, но кое-где (даже в access) есть слово top, позволяющее получить первые элементы таблицы:

select top 50 *
from comments
order by date desc

что-то типа такого

[info]justbulat

January 8 2009, 10:23:54 UTC 3 years ago

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

[info]itman

January 8 2009, 15:32:17 UTC 3 years ago

Я бы даже сказал больше - это способ можно развить и поддерживать на уровне апача.

[info]leonov

January 8 2009, 11:19:21 UTC 3 years ago

Ну даже если оставить в стороне невозможность оптимизации кривого запроса (во что верится с трудом), воткните генерацию этого блока в крон, раз в 10-30 минут.

[info]ivbeg

January 8 2009, 11:38:51 UTC 3 years ago

Достаточно вынести его из веб сер сервера в отдельный скрипт который дергать cron'ом 200-300 раз в сутки и кидать результаты в memcached. А уже из memcached показывать блоком на сайте как альтернатива статики

[info]sply

January 8 2009, 14:01:22 UTC 3 years ago

Есть стандартный паттерн, когда сложно менять логику в клиенте, выносить ее в базу:

создать отдельную таблицу lastcomments, из нее будут читаться записи для вывода в этот блок
по крону раз в N минут из всей таблицы комментариев (которая 30 Мб) вытаскивать в lastcomments небольшое кол-во комментариев. Например, за последние сутки, с условием типа insert into lastcomments select * from comments where created > NOW() - INTERVAL 1 DAY

в коде, который генерирует блок изменить таблицу comments (или как она у вас называется) на lastcomments.

[info]justbulat

January 8 2009, 18:01:01 UTC 3 years ago

правильно! а если юзеры будут ругаться что комменты вносятся в базу по полчаса, то объяснять это кривостью sql LOL

[info]sply

January 8 2009, 18:08:43 UTC 3 years ago Edited:  January 8 2009, 18:09:26 UTC

Вам рецепт точно не поможет. А тот, кто в ясном сознании, вполне поймет, что выбирать не нагружая этим сервер можно хоть раз в минут.

[info]alexclear

3 years ago

  • Loading...

[info]sply

3 years ago

  • Loading...

Anonymous

3 years ago

  • Loading...

[info]j31

January 9 2009, 05:29:51 UTC 3 years ago

А может и правда, попробовать drupal? (это без каких-либо намеков на вебпланету)

[info]sinodov

January 9 2009, 10:56:52 UTC 3 years ago

Я достаточно насмотрелся на друпал и не вижу у него никаких преимуществ.

[info]KID [perm.ru]

January 11 2009, 08:53:57 UTC 3 years ago

В таблице b_forum_message должно быть поле TOPIC_ID, которое определяет, к какой теме обсуждения принадлежат комментарии. Достаточно добавить в условие запроса ограничение
TOPIC_ID = $topic_id
, например так:
SELECT FM.*, DATE_FORMAT(FM.POST_DATE, '%d.%m.%Y %H:%i:%s') as POST_DATE
FROM b_forum_message FM
WHERE 1 = 1 AND ((FM.FORUM_ID = 8 )) AND ((FM.APPROVED = 'Y' )) and TOPIC_ID = $topic_id

, чтобы объём выбираем данных уменьшился в сотни раз (а точнее примерно в столько раз, сколько существует тем).
В переменную $topic_id перед запросом нужно записать значение идентификатора текущего топика. Его можно получить в окружении CMS или сделав дополнительный "дешёвый" запрос к базе.

Anonymous

January 20 2009, 17:41:27 UTC 3 years ago

А покажите explain запроса, если не жалко ?
для этого не нужно быть суперпользователем. просто explain select ...<весь тот текст>
Я уже вижу низкоселективный индекс и using filesort; Это ад, даже без ORM.

Запрос могли оставить в этом виде только из-за требований совместимости с mysql 4.0.
И решение добавить лишний индекс, тоже могли посчитать неудобным массам и забраковать. Что поделать - промышленный продукт.
Вам, возможно, поможет если переписать с подзапросом в скобках и создать дополнительный индекс.

Anonymous

3 years ago

  • Loading...
Create an Account
Forgot your login or password?
Facebook Twitter More login options
English • Español • Deutsch • Русский…