Скрыть

Re:у вас трекер тупит

Там, мягко говоря, по паре sql-запросов на каждое сообщение. Ещё б он не тупил.

Скрыть

Re:у вас трекер тупит

А, кстати, ещё баг - в поле с часами можно вбить символ: ♂ или ♀, и тогда трекер выдаёт странную подборку "За 0 часов." При этом, если вбить просто 0, подборка другая.

Скрыть

Re:у вас трекер тупит

Ну ясен хуй. Это же фича. По символу ♂ он выдает подборку для мужиков, по ♀ для баб, а по нулю для всех. :)

Скрыть

Re:у вас трекер тупит

Это не баг, это фича.

Скрыть

Re:у вас трекер тупит

Что характерно сегодня утром тоже попробовал воодить 9999 часов, поняв, что это несколько подвешивает запрос, подумал что надо глянуть код на предмет возможного ДОСа...

Скрыть

Re:у вас трекер тупит

> Что характерно сегодня утром тоже попробовал воодить 9999 часов

Что это вас всех именно сегодня разобрало этим страдать?

Скрыть

Re:у вас трекер тупит

это в Матрице коллизии к концу года

Скрыть

Re:у вас трекер тупит

Вообще да, Рождество же Христово сёдни

Скрыть

Re:у вас трекер тупит

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

Там определяется порядковый номер сообщения в треде, чтобы по нему посчитать, на какой странице это сообщение находится, учитывая выбранное пользователем количество сообщений на странице. Проблема в том, что этот номер получается методом вытаскивания всех сообщений для треда (точнее, их id) и подсчётом в пхп циклом (вот тут в get_msg_number_by_tid). Соответственно, я не вижу сходу способа определять этот номер как-нибудь внутри того запроса, не дёргая по селекту на каждое сообщение в трекере, что, имхо, страшновато выглядит. Если знатоки sql-извращений знают, как это решить, то пусть подскажут.

Учитывая, что у нас сообщения не удаляются и не скрываются, можно было бы устроить подсчёт прям при создании сообщения, и записывать результат в БД уже там. Но сейчас уже поздно, а добавлять поле и прогонять всю базу через скрипт лень.

Скрыть

Re:у вас трекер тупит

>символ: ♂ или ♀
卐!

Скрыть

Re:у вас трекер тупит

> через один запрос с JOIN-ом

Если там MySQL, то JOIN-ы наверное лучше не трогать.

> номер получается методом вытаскивания всех сообщений для треда (точнее, их id) и подсчётом в пхп циклом (вот тут в get_msg_number_by_tid). Соответственно, я не вижу сходу способа определять этот номер как-нибудь внутри того запроса,

Если речь про запрос по ссылке, то вот так:

sql


SELECT count(1)-1 AS Result FROM comments WHERE tid = \'::0::\' and id <= \'::1::\'


> не дёргая по селекту на каждое сообщение в трекере

Чота я сомневаюсь, что это можно решить красиво.
Чтобы избежать дёргания, нужно запрос приведённый выше как-то втиснуть подзапросом в этот код из classes/messages.class.php, чтобы он возвращал номер сообщения:

php


        function get_messages_for_tracker($hours)
        {
                if($hours>1)
                        $str = '- '.$hours.' hours';
                else
                        $str = '- 1 hour';
                $timestamp = gmdate('Y-m-d H:i:s', strtotime($str));
                $sel = self::$baseC->query('SELECT * FROM comments WHERE timest > \'::0::\' ORDER BY timest DESC, id DESC',
                                           'assoc_array', array($timestamp));
                return $sel;
        }

 

Боюсь, что решение получится специфичным для заданного диалекта БД. Проще тогда в трекере вообще делать ссылку на заглушку php (get_cooment.php?comment_id=xxxx), которая будет считать страницу и редиректить на правильный урл, когда его запрсит пользователь, чем считать пагинацию на каждый просмотр трекера.

Скрыть

Re:у вас трекер тупит

> Проще тогда в трекере вообще делать ссылку на заглушку php (get_cooment.php?comment_id=xxxx), которая будет считать страницу и редиректить на правильный урл, когда его запрсит пользователь, чем считать пагинацию на каждый просмотр трекера.


Поддерживаю, считать пагинацию на каждую строку в трекере это бред.

Скрыть

Re:у вас трекер тупит

>Если там MySQL, то JOIN-ы наверное лучше не трогать.
Там постгрес. Да и, как мне кажется, даже мускулевские джойны не будут так ужасны по сравнению с сотнями запросов, которые сейчас выдаются. Впрочем, это уже не важно, так как джойны сделать не получится.

>SELECT count(1)-1 AS Result FROM comments WHERE tid = \'::0::\' and id <= \'::1::\'
Ну да, в общем, почти те же яйца, только без участия пхп. Жаль.

>Проще тогда в трекере вообще делать ссылку на заглушку php (get_cooment.php?comment_id=xxxx)
Я тоже думал об этом, как о другом варианте решения. В принципе, он не хуже варианта "посчитать номера заранее", так что я, возможно, как-то так и поступлю.

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

Скрыть

Re:у вас трекер тупит

> лишний редирект, но что ж поделать.

Без редиректа: get_comment.php?comment_id=XXXX#msgXXXX
Т.е. из get_comment.php страницу сразу отрисовываешь как встарь с якорями

Кстати, кажется капча после восстановления сервера что-то кешироваться начала - ты там ничего не "улучшал" в этом плане?

Скрыть

Re:у вас трекер тупит

Да и сделал бы [альтернативный] трекер в виде последние N тем, чтобы одинаковые темы не дублировались

Скрыть

Re:у вас трекер тупит

>Без редиректа
Можно и без него, в принципе. Правда, тогда у нас будут ссылки двух видов на один и тот же контент, обычно это не любят.

>Кстати, кажется капча после восстановления сервера что-то кешироваться начала - ты там ничего не "улучшал" в этом плане?
Нет.

Скрыть

Re:у вас трекер тупит

>Да и сделал бы [альтернативный] трекер в виде последние N тем, чтобы одинаковые темы не дублировались
Можно, в принципе, правда нас ведь ждёт новая версия движка, думаю, может его дождаться.

Скрыть

Re:у вас трекер тупит

Когда?

Скрыть

Re:у вас трекер тупит

>Когда?
Не знаю:)

Скрыть

Re:у вас трекер тупит

> тогда у нас будут ссылки двух видов на один и тот же контент

Это твоё сообщение доступно по следующим ссылкам:
http://rulinux.net/thread_40516#msg186211
http://rulinux.net/thread_40516_page_1#msg186211
http://rulinux.net/thread_40516_page_0#msg186211
http://rulinux.net/thread_40516_page_19#msg186211
и т.п.

Скрыть

Re:у вас трекер тупит

> Когда?

Уже!

Скрыть

Re:у вас трекер тупит

Это дзен-форум. На нём по линку на лолксы, ошибка 500

Скрыть

Re:у вас трекер тупит

И что это, милый?

Скрыть

Re:у вас трекер тупит

Пруф или не было.

Скрыть

Re:у вас трекер тупит

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

Скрыть

Re:у вас трекер тупит

> Пруф или не было.



http://i39.tinypic.com/255v1qw.png

Скрыть

Re:у вас трекер тупит

Это да, но причем тут лолксы?

Скрыть

Re:у вас трекер тупит

> Это да, но причем тут лолксы?

Просто, с утра во мне проснулись телепатические способности. :)

Скрыть

Re:у вас трекер тупит

>>Это да, но причем тут лолксы?
В некие замшелые годы лолксами назывался раздел talks на одном местечковом форуме.

И уже потом это название перешло на ивладовский чатик.

Скрыть

Re:у вас трекер тупит

>ввёл в поле "за последние ... часа" 100000, трекер мало того что думал секунд двадцать, так ещё и ничего не вывел в итоге
Так, вот по идее теперь он не будет думать 20 секунд, а будет почти сразу выводить ничего. Потому что php memory limit в 128 мб, а 100000 часов флуда в него просто не влезает ещё на этапе pg_fetch_assoc. А повышать лимит не стоит, имхо.

Но вот на 7000 часах, например, уже вполне так ничего. Если будут какие-то баги, пишите.