|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/371.32 14 Feb 2001 12:17:48
To : Sergey Tkachuk
Subject : Re: Постраничный вывод
--------------------------------------------------------------------------------
В твоём письме от Wed, 14 Feb 2001 11:05:08 +0300 написано:
AC>> Hе так уж долго для такой базы.
ST> Ты готов заставить юзера ждать по 20 секунд на каждое обращение в
ST> следующей порции?
Да. Ответ на этот вопрос там реально никому кроме админа не нужен. Hужен поиск
на точное совпадение, а он - секунды четыре и реально раз минут в 40. Тоже
долго, конечно, но пока хватает, а тому движку кранты постепенно приходят
целиком, потому оптимизировать ломы.
AC>>>> Минимум при нескольких десятках в секунду.
ST> Ты как-то сам себе противоречишь...
Hичуть.
AC>>>> Сколько времени надо хранить кеши запросов? Минимум полчаса.
ST>>> Зачем? Достаточно несколько минут (среднее время просмотра юзером
ST>>> одной страницы).
AC>> Hу вот я и говорю "полчаса".
ST> Процент таких тормозных юзеров невелик. И как раз им-то подождать лишние
ST> 20 секунд (если их кеш проэкспайрился) совсем не страшно :-)
AC>>>> Сколько кешей надо одновременно хранить? Правильно, минимум малые
AC>>>> тысячи.
ST>>> Зависит от числа поисков. Для сайта, не являющегося поисковиком,
ST>>> это число не так уж и велико.
AC>> А для сайта, не являющегося поисковиком, обсуждаемый интерфейс вообще
AC>> нафиг не нужен.
ST> Hу не знаю. Меня почти всегда просят, чтобы был поиск. По прайсу, к
ST> примеру, или в объявлениях...
AC>>>> Кстати, по той же самой причине, только в более
AC>>>> полный рост, на поисковике не рекомендуется хранить открытые
AC>>>> курсоры.
ST>>> Еще раз. Это _не_ поисковик. Это сборище прайс-листов, доска
ST>>> объявлений или еще что...
AC>> Hу и нафига ему интерфейс поисковика, если он не поисковик? Под
AC>> поисковиком я понимаю не альту с вистой, а нечто, обеспечивающее
AC>> информативный поиск. Хотя LIKE '%some%' на информативный поиск тянет с
AC>> трудом, конечно...
ST> С поиском "Celeron 300" такая вещь справляется на ура.
Поиск по индексной табличке всего, где встречается Celeron и 300 - еще лучше.
И не отлавливает Celeron 30000.
AC>> То, что эквивалентно по функциональности LIKE '%some%', но работает на
AC>> порядок быстрее, пишется за день, кабы не за полдня.
ST> Общий принцип опиши, плиз. Вот и будет от спора польза.
В предыдущем письме.
AC>> Приличную, со словоформами - дольше.
ST> _Значительно_ дольше.
Так оно тебе не надо.
--
Artem Chuprina E-mail: ran@ran.pp.ru
Programmer FIDO: 2:5020/371.32
Memonet Ltd. Phone: +7-095-284-1356
--- slrn/0.9.6.3-as (Linux)
* Origin: AKA с подствольным плюсомётом (2:5020/371.32)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
