Posted: Thu Jan 15, 2004 4:48 pm (спустя 1 час 2 минуты)
Post subject:
Что хотелось бы:
1) сделать все же систему индексирования, чтобы поиск был в [10] раз быстрее (можно просто спросить, сделать ли индекс) 2) сделать сортировку по количеству совпадений 3) сделать [кэширование] результата и разделение на страницы 4) если не делать разделение на страницы, то выводить результаты сразу через flush() (так получится во многих случаях лучше)
А так - форма очень хорошая и юзабельная. (вывод результатов тоже), только скорость явно подкачала
Posted: Thu Jan 15, 2004 5:24 pm (спустя 36 минут)
Post subject:
yUAC wrote:
1) сделать все же систему индексирования, чтобы поиск был в [10] раз быстрее (можно просто спросить, сделать ли индекс)
то, думаю, пока отпадает. Скрипт писался для Денвера и для малых и средних сайтов. Если брать во внимание Денвер, то кому захочется делать индексирование документации? Если же брать второе, то на малых и средних сайтах это просто не к чему (объём небольшой, да и индексировать заново сайт после нескольких изменений — мало приятное занятие).
yUAC wrote:
2) сделать сортировку по количеству совпадений
Вот это хорошее предложение (сам об этом думал). Тут есть один вопрос. Такое действие можно сделать путём создание массива (хотя, лучше хеша) с последующей сортировкой и выводом результатов. Вопрос, собственно, в том, не «утяжелит» ли этот процесс сам поиск (то есть, как скажется такая функция на скорость работы).
yUAC wrote:
3) сделать [кэширование] результата и разделение на страницы
Ну это уже перебор. Поиск изначально не был рассчитан на такие возможности. Тем более мы сошлись с ДК на том, что пользователь вообще не поёдёт на следующую страницу, а, следовательно, это бессмысленно (так же следует учитывать алгоритм поиска, который совершенно не рассчитан на постраничный вывод).
yUAC wrote:
4) если не делать разделение на страницы, то выводить результаты сразу через flush() (так получится во многих случаях лучше)
Как я понимаю, Вы говорите на PHP-ном «жаргоне». Можно подробнее (на алгоритмическом языке) что это делает?
yUAC wrote:
только скорость явно подкачала
На счёт скорости это Вы зря. Только подумайте, сколько теперь времени надо, чтобы что-нибудь найти в документации?! (-;
Posted: Thu Jan 15, 2004 7:52 pm (спустя 30 минут)
Post subject:
yUAC wrote:
Нет, по сравнению с чтением файлов, сортировка занимает очень мало времени
Что ж, как только появится секунда свободного времени — сразу этим займусь (скорее всего, что пока Денвер выйдет с версией скрипта, которая уже сущ-ет).
yUAC wrote:
ИМХО в Perl это тоже есть, эта штука сразу отдает браузеру буфер вывода после вызова этой функции (конструкции).
Если честно, то никогда не встречался с этой функцией. В документации Perl (которая есть в электронном виде под рукой) отыскал такое вот утверждение:
Quote:
$| $OUTPUT_AUTOFLUSH Если присвоить этой переменной не нулевое значение то будет сброс буфера вывода после каждой операции вывода. Значение по умолчанию -0
Это из той же области?
yUAC wrote:
Поиск по индексу документации занимает менее 0.5 сек.
Всё это я понимаю. Ессно дело, что поиск по индексу — это совсем другое. Но опять же повторяю, что этот скрипт писался не для этих целей. Кому захочется индексировать документацию к Денверу (при этом надо учитывать, что индекс занимает определённое место). Да и на сайтах мало кому захочется индексировать сайт заново каждый раз при добавлении новой статьи, например.
Posted: Thu Jan 15, 2004 8:51 pm (спустя 58 минут)
Post subject:
Ant wrote:
Это из той же области?
Угу.
Ant wrote:
Да и на сайтах мало кому захочется индексировать сайт заново каждый раз при добавлении новой статьи, например.
Можно пополнять индекс (делать "синхронизацию"), заменив только изменившиеся файлы. В любом случае, для документации по крайней мере можно сделать такую вещь. + к тому, у меня например в папке /home/ находится 200 мегабайт :).
Posted: Fri Jan 16, 2004 4:30 am (спустя 6 часов 4 минуты)
Post subject:
Я думаю, что индексирование тут — это перебор. Слишком сложно поддерживать.
Ant wrote:
$| $OUTPUT_AUTOFLUSH Если присвоить этой переменной не нулевое значение то будет сброс буфера вывода после каждой операции вывода. Значение по умолчанию -0 Это из той же области?
Да, это оно. Но только тогда сортировку не получится сделать.
Что касается кэширования — это для того, чтобы поиск по одному и тому же запросу второй раз происходил мгновенно. Делается довольно легко — достаточно перед выводом результатов записывать их в файл "/tmp/dnsearch/"+urlencode($search_params), а при следующем поиске — пытаться вначале считать оттуда (сели time()-(stat $fname)[9]<3600).
Posted: Fri Jan 16, 2004 4:26 pm (спустя 11 часов 56 минут)
Post subject:
Дмитрий Кóтеров wrote:
Что касается кэширования — это для того, чтобы поиск по одному и тому же запросу второй раз происходил мгновенно.
Ну, это и понятно.
На счёт предложенного алгоритма... Как я понял, Вы предлагаете каждый найденный результат записывать в файл с определённым названием (в т.ч. и с параметрами поиска в названии), а затем поочерёдно проверять, не совпадают параметры поиска и не перешло ли определённый барьер время создания такого файла. Верно?
Только, может быть всё записывать в один файл через разделители? При этом опять же получается некий индекс.
P.S. Опять обновил версию скрипта. См. первый пост.
Posted: Fri Jan 16, 2004 5:45 pm (спустя 1 час 19 минут)
Post subject:
Зачем в один файл? Один запрос — один файл, как генерировать его имя (пример) — я уже писал. Имена найденных файлов можно записывать прямо в текстовом виде — по одной строке на файл. Реализация — максимум строк 5-6, и, заметьте, это не вносит структурных изменений в библиотеку (кэширование вообще всегда реализуется в виде дополнительного слоя, легко отделяющегося от основного кода).
Время создания нужно проверять, чтобы кэш иногда устаревал (вдруг документы поменяются).
Posted: Fri Jan 16, 2004 5:47 pm (спустя 1 минуту 38 секунд)
Post subject:
Кстати, Антон, обратите внимание, что я чуть-чуть изменил шаблон form.html — улучшил «резиновость» (и прислал Вам полную версию). А Вы мне прислали новую версию со старой формой, пришлось вручную вставлять назад.
Posted: Fri Jan 16, 2004 6:27 pm (спустя 40 минут)
Post subject:
Дмитрий Кóтеров wrote:
Один запрос — один файл
Ну, это я и имел ввиду. То есть, при каждом «новом» поиске создавать файл со специфичечким названием (по которому потом можно определить, совпадает ли новый поиск с кешем) и записывать туда только пути к файлам, в которых поиск был удачным. Далее, если скрипт видит, что кеш ещё не устарел, то считывает массив оттуда и подсовывает этот список в функцию поиска. Я правильно понял?
Есть одна идея: может быть сделать checkbox с возможностью принудительного поиска через кеш («искать с помощью кеша, если это возможно»)?
Дмитрий Кóтеров wrote:
Кстати, Антон, обратите внимание, что я чуть-чуть изменил шаблон form.html — улучшил «резиновость» (и прислал Вам полную версию). А Вы мне прислали новую версию со старой формой, пришлось вручную вставлять назад.
Это когда по почте высылал? Если да, то эту ошибку я понял давно, а здесь выложен полностью Ваш шаблон (кстати, повторяю, что сегодня я обновил скрипт и выложил его здесь, всё в том же первом посте).
Posted: Fri Jan 16, 2004 8:18 pm (спустя 16 минут)
Post subject:
Ant wrote:
Если только он не устарел
Если кэш устарел, то он не существует! У кэша вообще может быть только 2 состояния: либо он есть (существует, валидный), либо его нет (пустой, не существует, инвалидный).
Posted: Fri Jan 16, 2004 8:32 pm (спустя 13 минут)
Post subject:
Дмитрий Кóтеров wrote:
Если кэш устарел, то он не существует! У кэша вообще может быть только 2 состояния: либо он есть (существует, валидный), либо его нет (пустой, не существует, инвалидный).
Posted: Sat Jan 17, 2004 1:14 am (спустя 4 часа 42 минуты)
Post subject:
В общем так. Как обычно я обновил в первом посте архив со скриптом.
Изменения: 1). Теперь может происходить кэширование результатов поиска, при чём: а). возможно указать надо ли делать кэширование или нет; б). кэширование происходит *полностью* (то биш, все данные, которые выводятся на страницу после поиска, пишутся в кэш); в). возможность самому выбрать время жизни кэша (по умолчанию — 1 час).
2). Появилась сортировка по количеству совпадений.
Прошу всех протестировать в работе данный скрипт. Я просто не в состоянии отловить всех ошибок (а они, скорее всего, есть).
P.S.
Дмитрий Кóтеров wrote:
Реализация — максимум строк 5-6,
Ну да... (=
Дмитрий Кóтеров wrote:
заметьте, это не вносит структурных изменений в библиотеку
Posted: Sat Jan 17, 2004 11:55 am (спустя 9 часов 22 минуты)
Post subject:
Ant wrote:
документация начнёт занимать в два раза больше (индекс, как никак).
Это смотря как туда записывать (у меня индекс документации получился чуть ли не в 5 раз меньше). Обычно индекс занимает существенно меньше места, и именно в этом он обычно выигрывает...
Posted: Sat Jan 17, 2004 2:05 pm (спустя 2 часа 10 минут)
Post subject:
yUAC wrote:
Это смотря как туда записывать (у меня индекс документации получился чуть ли не в 5 раз меньше).
Ну, на счёт 5 раз от действительного значения (если сравнивать с исходным размером, полностью выбросив из него то, по чему поиск не производится)... что-то я сильно сомневаюсь. Но даже если и так, то ( 200мб / 5 ) = 40мб нового лишнего «веса». Мало приятного, если место на хостинге осталось мало...
Posted: Sun Jan 18, 2004 12:34 am (спустя 8 часов 17 минут)
Post subject:
Ant wrote:
Там ещё с десяток операций нужно проделать. Меньше, конечно, но всё же.
Погодите, какой «десяток операций»? Это полный код (разве что не все параметры поиска учитываются, но это еще 2 строчки), и он подходит для чего угодно, а не только для поиска.
Posted: Sun Jan 18, 2004 12:39 am (спустя 5 минут)
Post subject:
Я понял, какие операции Вы имели в виду. Что ж, если хранить в кэше еще и ошибки, тогда да.
Кстати, кэшировать лучше прежде всего в /tmp/dnsearch (и только если /tmp не существует, в своей директории). Это относится и к хостингу: там тоже обычно есть /tmp, в которой удобно хранить разные временные файлы.
И, конечно, директорию кэша нужно каждый раз создавать заново (если она не существует), а то пользователь будет весьма смущен, если вдруг ее удлит. В заглушке sendmail сделано так:
Posted: Sun Jan 18, 2004 12:50 am (спустя 11 минут)
Post subject:
Дмитрий Кóтеров wrote:
Я понял, какие операции Вы имели в виду. Что ж, если хранить в кэше еще и ошибки, тогда да.
И не только. Кэш ещё надо проверять на инвалидность, а это — ещё лишние 4-5 строк. Плюс, надо удалять кеш при его «критическом» размере. Там много чего надо сделать, чтобы учесть все тонкие моменты.
Дмитрий Кóтеров wrote:
Кстати, кэшировать лучше прежде всего в /tmp/dnsearch
Это всё настраиваемо, так что не думаю, что это создаст какие-нибудь трудности.
Дмитрий Кóтеров wrote:
, конечно, директорию кэша нужно каждый раз создавать заново (если она не существует), а то пользователь будет весьма смущен, если вдруг ее удлит.
Хорошая идея, спасибо.
Есть у меня один вопрос (о путях поиска, которые скрипт так «умно» обрабатывает): Если указывается URL, то всё окей; Если указывается путь вида «z:/home», то так же всё окей; Но, если указывается путь вида «/home/» (ну, или вроде того), то получается весьма интересная штука: скрипт выводит все результаты в виде «/home/что_то/там/нашлось.html». Но система не знает, как открыть этот файл, так как не указан диск. Что можно сделать в данной ситуации?
Posted: Sun Jan 18, 2004 12:54 am (спустя 3 минуты)
Post subject:
О, господи!
Зачем же Вы HTML-то закэшировали? Кэширование должно работать на том же слое, что и система, которая кэшируется, и быть невидимым из более высоких слоев. В частности, если кэширование идет на уровне контроллера, то кэшируются только данные без привязки к шаблону, а если на уровне шаблона (как в шаблонизаторе) — то только на уровне HTML (не образая внимание на структуру данных — это обычный текст). У Вас же мешанина получилась.
Я скажу, чем это неудобно. Если бы кэшировались только результаты поиска (а именно — найденные пути к файлам), то очень легко было бы приделать разбивку по страницам. А как теперь ее приделать? Практически невозможно. Кроме того, теперь изменение шаблона не отразится на внешнем виде закэшированного результата.
А следовательно, нарушен главный принцип кэширования — это его прозрачность.
Posted: Sun Jan 18, 2004 1:11 am (спустя 17 минут)
Post subject:
Дмитрий Кóтеров wrote:
О, господи!
Воистину... (-;
Дмитрий Кóтеров wrote:
У Вас же мешанина получилась.
Ну, не скажите.
Дмитрий Кóтеров wrote:
Если бы кэшировались только результаты поиска (а именно — найденные пути к файлам)
...то надо было бы делать весь поиск заново. Как не крути, а надо было бы делать повторные операции, которые уже были сделаны.
Дмитрий Кóтеров wrote:
то очень легко было бы приделать разбивку по страницам. А как теперь ее приделать?
Ну, с этим я с Вами очень долго буду спорить, после того, как Вы ответите мне на мой предыдущий вопрос (о путях). Разбивку на страницы я как раз-таки уже сделал (именно такая структура позволила её реализовать в два счёта) и осталась одна проблема: с путями.
Дмитрий Кóтеров wrote:
А следовательно, нарушен главный принцип кэширования — это его прозрачность.
Posted: Sun Jan 18, 2004 1:32 am (спустя 21 минуту)
Post subject:
Ant wrote:
...то надо было бы делать весь поиск заново
Это, наверное, Вы верно заметили — структуру пришлось бы переделать. Ну да все равно, я писал про кэширование в общем случае.
Ant wrote:
Да на кой нам эта прозрачность?
Из идеологических соображений. (-; Вообще, все идеологические соображения вдруг резко становятся практическими, как только размер программы насчинает возрастать.
Ant wrote:
Но, если указывается путь вида «/home/» (ну, или вроде того), то получается весьма интересная штука: скрипт выводит все результаты в виде «/home/что_то/там/нашлось.html». Но система не знает, как открыть этот файл, так как не указан диск. Что можно сделать в данной ситуации?
Боюсь, только указать слева имя диска. Как его вычислить — боюсь, только через вызов system("dir>/tmp/a") (использовать `` — обратные апострофы — не рекомендуется, потому что в ActivePerl с этим иногда глюки — система виснет) и последующий анализ получившегося файла. А кроме того, приписать префикс "file://" к началу пути.
Да, только что мне удалось экспериментальным путем выяснить, (stat '.')[0] в Windows для A: возвращает 0, для B: — 1 и т.д., т.е. можно попробовать сделать chr(ord('A')+(stat '.')[0]) (правда, я не проверял это в Windows 95, только в 2003).
Posted: Sun Jan 18, 2004 2:11 am (спустя 39 минут)
Post subject:
Дмитрий Кóтеров wrote:
структуру пришлось бы переделать
Тут немного не так. В этом случае структуру бы вообще не пришлось переделывать. Просто берём и «подсовываем» программе список файлов для поиска из кэша. Вот и всё. Я тоже хотел так сделать, но при работе пришла идея: «зачем, собственно, делать кэш, если поиск всё равно будет происходить?». После этого я хотел сделать так, чтобы в кеш записывались только найденные значения (потом из него доставать и «подсовывать» функциям, которые обрабатывают шаблоны). Но это оказалось уже слишком сложным, и я решил просто писать выходные данные в файл.
Дмитрий Кóтеров wrote:
Вообще, все идеологические соображения вдруг резко становятся практическими, как только размер программы насчинает возрастать.
Вот здесь Вы правы!
Дмитрий Кóтеров wrote:
А кроме того, приписать префикс "file://" к началу пути.
Ага. Я пробовал так сделать. Но на путь вроде «file:///usr/...» система очень сильно плевалась. (-;
В общем, я оставлю возможность поиска таким способом, но это будет на совести и пользователя. То есть, остаются 2 основных способов поиска: 1). «z:/home/...»; 2). «http://localhost/something».
Всё остальное будет на совести у пользователя (может просто быть удобным указание в качестве пути «/home/» — ищется-то всё нормально).
P.S. Завтра выложу новую версию с постраничным выводом (я уже всерьёз начинаю подумывать над индексом (-; ).
Posted: Sun Jan 18, 2004 2:17 am (спустя 6 минут)
Post subject:
Ant wrote:
этого я хотел сделать так, чтобы в кеш записывались только найденные значения (потом из него доставать и «подсовывать» функциям, которые обрабатывают шаблоны).
Вообще, обычно именно так и делается. (-; Кэшируют то, что больше всего нагружает процессор, при этом стараются, чтобы это «нечто» было минимально параметризировано (т.е. зависело от минимального числа параметров).
Если же потом обнаруживается, что какая-то другая часть тоже нагружает процессор — просто делают второе кэширование, не обращая внимание на первое. В этом преимущество «прозрачности».
Ant wrote:
Но на путь вроде «file:///usr/...» система очень сильно плевалась. (-;
И правильно делала. Откуда ж браузер узнает текущий диск?
Ant wrote:
z:/home/...
Вы знаете, такой путь нельзя ни в коем случае оставлять в Денвере, ибо имя виртуального диска неизвестно (это не обязательно Z: — можно ставить куда угодно).
Posted: Sun Jan 18, 2004 11:04 am (спустя 8 часов 46 минут)
Post subject:
Дмитрий Кóтеров wrote:
Вообще, обычно именно так и делается. (-;
Согласен.
Дмитрий Кóтеров wrote:
Кэшируют то, что больше всего нагружает процессор, при этом стараются, чтобы это «нечто» было минимально параметризировано (т.е. зависело от минимального числа параметров).
Ну, хорошо. Давайте прямо говорить. Изменить то, что есть сейчас на то, что предлагаете Вы — дело 5-ти минут (т.е., очень просто). Менять? Я просто не особо понимаю, как надо поступть.
С одной стороны — прозрачность, кэш будет занимать на порядок меньше места и т.п. С другой — не надо делать лишний раз поиск (за то надо делать больше телодвижений).
Всё это отлично, но тут пришла идея: что если сделать индекс? Если оставить кэширование на том уровне, что есть сейчас, то индекс с лёгкостью будет кэшироваться по точно такой же схеме, что и обычный поиск. Если же в кэше указывать только пути к файлам, то кэширование индекса... даже пока и не знаю как это сделать (пока не рассматривал оптимальную структуру оного).
Что думаете? Может ещё кто-нибудь подключится к решению проблемы?
Дмитрий Кóтеров wrote:
И правильно делала. Откуда ж браузер узнает текущий диск?
Естесственно.
Дмитрий Кóтеров wrote:
Вы знаете, такой путь нельзя ни в коем случае оставлять в Денвере, ибо имя виртуального диска неизвестно (это не обязательно Z: — можно ставить куда угодно).
Так вот я про это и говорю! Что делать-то с Денвером (где Вами была указана опция поиска по корневосу каталогу)?
Posted: Sun Jan 18, 2004 8:38 pm (спустя 7 часов 43 минуты)
Post subject:
Ant wrote:
Всё это отлично, но тут пришла идея: что если сделать индекс? Если оставить кэширование на том уровне, что есть сейчас, то индекс с лёгкостью будет кэшироваться по точно такой же схеме, что и обычный поиск. Если же в кэше указывать только пути к файлам, то кэширование индекса... даже пока и не знаю как это сделать (пока не рассматривал оптимальную структуру оного).
Что Вы подразумеваете под «индексом»? Ничего не понимаю.
Ant wrote:
Ну, хорошо. Давайте прямо говорить. Изменить то, что есть сейчас на то, что предлагаете Вы — дело 5-ти минут (т.е., очень просто). Менять? Я просто не особо понимаю, как надо поступть.
Это Вам решать. (-; Главный критерий — это чтобы программа работала, все остальное — лишь детали.
Ant wrote:
С другой — не надо делать лишний раз поиск (за то надо делать больше телодвижений).
Вот этого я не понимаю. Почему «лишний раз поиск»? В кэше же сохраняются имена файлов, в которых было что-то найдено. Таких файлов — обычно штук 10...100. Искать в них слово для подсветки его контекста — относительно грошовая операция, а если будет разбиение на страницы — то и подавно.
Ant wrote:
Что делать-то с Денвером (где Вами была указана опция поиска по корневосу каталогу)?
Выше я писал про решение с (stat $fname)[0].
Ant wrote:
какие права доступа надо назначать
0770 для директорий, для файлов — по умолчанию, можно не менять. Для директорий надо ставить именно 0770 потому, что они могут создаваться в /tmp, а там права чтения для всех ни к чему.
Ant wrote:
Хочу сделать опцию «поиск в найденном».
Вы уверены, что это юзабельно? По-моему, мало кто этим пользуется. К тому же если сделать несколько раз поиск в найденном, очень легко запутаться.
Ant wrote:
Вот блин, придётся и так и эдак делать. Одно плохо: размер кэша оставляет желать лучшего... Как бы это сделать по солиднее?
Зачем делать «и так, и эдак»? Можно просто хранить в кэше имена файлов, в которых было что-то найдено, и все, больше ничего. Тогда и размер будет маленьким.
All times are GMT + 3 Hours Goto page 1, 2, 3, 4, 5, 6Next
Page 1 of 6
You cannot post new topics in this forum. You cannot reply to topics in this forum. You cannot edit your posts in this forum. You cannot delete your posts in this forum. You cannot vote in polls in this forum. You cannot attach files in this forum. You can download files in this forum.
Поиск
Обновления
Неотв.
История
Последние
Memberlist
Usergroups
Statistics
Profile
Log in to check your private messages
Register
Log in
Posted
