+  HandyCache форум
|-+  Главная категория» Новые предложения» Структура кэша. Можно ли усовершенствовать?
Имя пользователя:
Пароль:
Страниц: 1 2 [3]  Все   Вниз
« предыдущая тема следующая тема »
  Отправить эту тему    Печать  
Автор Тема: Структура кэша. Можно ли усовершенствовать?  (Прочитано 35613 раз)
0 Пользователей и 1 Гость смотрят эту тему.
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #40 : 30 мая 2011, 18:47:39 »
Если очень хочется куда-то эту кодировку записать, можно создавать файлик meta.txt в корне каждого хоста и вписывать ее туда. Кодировка в пределах сайта одна и таже же, кроме случаев лютой патологии.

Вообще можно всякого туда понавписывать. Реальный адрес хоста, например (с www. или без); номер порта, если нестандартный; логин:пароль@ тоже лучше туда чем в названии папки.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #41 : 30 мая 2011, 22:59:13 »
Цитата: mirny от 30 мая 2011, 18:47:39
Если очень хочется куда-то эту кодировку записать

Это не прихоть, а реальная необходимость, подкрепленная многолетним опытом!

Цитировать
можно создавать файлик meta.txt в корне каждого хоста и вписывать ее туда.

Уже обсуждалось ранее, но это увеличит количество дисковых операций и, следовательно, замедлит работу HC.
Решили, что оптимальнее будет прикрутить к HC базу данных SQLite для хранения мета-данных, но это пока не реализовано...

Цитировать
логин:пароль@ тоже лучше туда чем в названии папки.

логин:пароль@ в URL HTTP запроса быть и не может! См. RFC 2616.


P.S. Но хранение кодировки это вовсе не единственное "слабое место" в твоем предложении! Остальные перечисленные проблемы как решать предлагаешь?
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #42 : 31 мая 2011, 01:17:02 »
>Но хранение кодировки это вовсе не единственное "слабое место" в твоем предложении!

>HC станет намного сложнее, т.к. в момент запроса определить точное имя файла будет невозможно. Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!

Ты так уверенно говоришь, что я чуть тебе не поверил. Это просто вопрос реализации, а не слабое место.

Рассмотрим пример для наглядности:

Случаев когда адрес оканчивается на / а там лежит не html исчезающе мало, поэтому предположить что файл в кэше будет называться #.html достаточно безопасно. Если произошла ошибка, срабатывает обработка исключений. И тогда действительно «Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!» В исключительном случае.


>логин:пароль@ в URL HTTP запроса быть и не может! См. RFC 2616.

в RFC может быть и не может, а в HC мне когда-то для такого случая правило пришлось писать

#5#~#True#~#^[^:/@]+:[^/@]+@(www\.)?(?=[^/]+/)(?# login:pass@example.com -> example.com)#~##~#False#~#True
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #43 : 31 мая 2011, 09:37:39 »
Цитата: mirny от 31 мая 2011, 01:17:02
Случаев когда адрес оканчивается на / а там лежит не html исчезающе мало, поэтому предположить что файл в кэше будет называться #.html достаточно безопасно. Если произошла ошибка, срабатывает обработка исключений. И тогда действительно «Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!» В исключительном случае.

Ты специально выбрал самый простой вариант? А если адрес заканчивается не на "/", а на ".php", ".cgi", "abcde?p=1" и т.п. Content-Type может быть любой. Будешь перебирать каждый раз все варианты? Это частый случай, а не исключительный!

Цитировать
в RFC может быть и не может, а в HC мне когда-то для такого случая правило пришлось писать
#5#~#True#~#^[^:/@]+:[^/@]+@(www\.)?(?=[^/]+/)(?# login:pass@example.com -> example.com)#~##~#False#~#True

Написать-то можно все, что угодно. Это не значит, что оно будет работать!
А реальность такова, что в HTTP-запросе не может быть никаких "логин:пароль@". Даже браузер такой URL не понимает!
Если же ты имел в виду FTP-запрос, то твое правило и на нем не будет работать. Проверь в тренажере...
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #44 : 31 мая 2011, 10:56:16 »
>Ты специально выбрал самый простой вариант?

Дело не в варианте, а в паттерне.

Код:
try:
    Берем самый ожидаемый Content-Type
except NoSuchFile:
    Не вышло, смотрим внутрь папки
   

Кстати вас ист «перебирать каждый раз все варианты»? Разве функция подобная glob() не существует в Делфи?

>Написать-то можно все, что угодно. Это не значит, что оно будет работать!

Это правило писалось для админки одного старого сайта. Таки работало. И в тренажере и на сайте.


>>ХЦ в автономном режиме сможет отдавать правильные заголовки, ориентируясь на расширение файла в кэше
>Он и сейчас это хорошо умеет, ориентируясь на сигнатуры файлов и те подсказки, которые сам себе оставил.

Умеет, но таки не очень хорошо. И txt и xml для него на одно лицо, выдает в виде хтмля.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #45 : 31 мая 2011, 14:04:58 »
Цитата: mirny от 31 мая 2011, 10:56:16
Кстати вас ист «перебирать каждый раз все варианты»? Разве функция подобная glob() не существует в Делфи?

Существует, но она и работает именно перебором всех файлов в директории, собственно также, как и glob() работает с помощью os.listdir(). И в Lua есть подобная функция lfs.dir().
Но работают они очень медленно, особенно когда в директории тысячи файлов, что совсем не редкость!

Цитировать
Это правило писалось для админки одного старого сайта. Таки работало. И в тренажере и на сайте.

Не знаю, где там у тебя работало, но ни один браузер в таком виде HTTP-запрос не пропустит! Если настаиваешь, то давай реальный рабочий пример.
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #46 : 31 мая 2011, 20:45:32 »
>Но работают они очень медленно, особенно когда в директории тысячи файлов, что совсем не редкость!

С этим можно справиться. Offline Explorer тому пример — по достижении тысячи файлов в папке начинает распихивать содержимое по служебным подпапкам.

>ни один браузер в таком виде HTTP-запрос не пропустит! Если настаиваешь, то давай реальный рабочий пример.

Не настаиваю. Давно было. Может и впрямь теперь по-другому.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #47 : 31 мая 2011, 22:31:21 »
Цитата: mirny от 31 мая 2011, 20:45:32
С этим можно справиться. Offline Explorer тому пример — по достижении тысячи файлов в папке начинает распихивать содержимое по служебным подпапкам.

Все равно такой кэш будет работать в разы медленнее, чем сейчас! Это не приемлемо.
Да и польза от такой структуры кэша спорна. Нерешенных проблем всплывает гораздо больше...
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #48 : 31 мая 2011, 22:55:56 »
>Все равно такой кэш будет работать в разы медленнее, чем сейчас!

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

Сравним с тем, что имеем сейчас:

  • если этот файл — html, то в него можно вписать, что он html (Великолепно, Кэп!)
  • если это не html, то мы SOSNOOLEY
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #49 : 01 июня 2011, 13:29:52 »
Цитата: mirny от 31 мая 2011, 22:55:56
Вовсе не факт. Замедление проявляется, только в случае, когда мы не угадали тип файла.

А гадать придется довольно часто! Допустим, зашли на новую страницу, ее файлов в кэше еще нет, но мы об этом не знаем. Что будем делать? Предположим, что это HTML. Проверили, файл на диске не найден. Что дальше? Продолжим предполагать: а вдруг это картинка JPG, а вдруг это картинка GIF, а вдруг это картинка TIF, а вдруг это флэш SWF, а вдруг это видео FLV и т.д. и т.п.? Будем перебирать все варианты? Их же десятки! И так с каждым новым файлом! Вот тебе и замедление в разы на ровном месте!

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

Не реально! И эвристика в случае выше не поможет. Все равно придется перебирать все варианты, чтобы не пропустить тот единственно верный.

Кстати, ты почему-то проигнорировал мою фразу, что список «Не обновлять» работает по исходным URL, а не по преобразованным. По путям и именам файлов в кэше он не работает! Или ты предлагаешь переделать логику работы списка "Не обновлять". Тогда практически всем пользователям придется корректировать свои правила в списке, да и работа самого списка существенно замедлится. Думаю, автор HC никогда на это не пойдет.

Цитировать
Сравним с тем, что имеем сейчас:

  • если этот файл — html, то в него можно вписать, что он html (Великолепно, Кэп!)
  • если это не html, то мы SOSNOOLEY

Тут ты не прав! Помимо HTML, HC прекрасно определяет типы и других файлов по сигнатурам. К примеру, картинки и видео. Некоторые файлы определяются по расширению, когда оно есть. А с остальными файлами прекрасно разбирается сам браузер! Уже и не помню, когда у меня были проблемы в браузере из-за работы HC в автономном режиме.

Тогда ради чего весь этот сыр-бор? Чтобы тебе было удобно вручную ковыряться в кэше? И ради этого придется решать кучу новых проблем:
- новый способ хранение кодировок HTML;
- изменение логики работы списка "Не обновлять";
- новый эвристический алгоритм угадывания имен файлов;
- существенное замедление работы HC с кэшем и увеличение нагрузки на диск.

Если у тебя сейчас есть реальные проблемы с определением типа файлов в автономном режиме HC, то давай конкретные ссылки. Подумаем, как решить эти проблемы с наименьшими потерями. Если ссылок таких нет и это лишь твое "хотение", то никто не мешает тебе реализовать его отдельным расширением. Все необходимое для этого в инструментарии HC уже есть...
« Последнее редактирование: 01 июня 2011, 13:57:13 от DenZzz » Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #50 : 02 июня 2011, 01:51:34 »
>Допустим, зашли на новую страницу, ее файлов в кэше еще нет, но мы об этом не знаем. Что будем делать?

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

Код:
http://somesite.com/xmldoc/  ->  somesite.com\xmldoc\#m
                                 somesite.com\xmldoc\#.xml

Что получается:

предположили #.html
    нет такого файла
обратились к #m
    PROFIT
#m тоже отсутствует
    тогда мы знаем, что такой страницы в кэше нет
   
   
и, разумеется, для случая \htmldoc\#.html указателя ставить не надо, ибо там не ошибешься.


>Тогда ради чего весь этот сыр-бор?

Просто нашел хороший проксик на питоне и теперь руки чешутся запилить всякие ништяки на его основе, которые я врятли увижу в HC. Пока определяюсь какие именно и стОит ли.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #51 : 02 июня 2011, 10:36:13 »
Цитата: mirny от 02 июня 2011, 01:51:34
Просто нашел хороший проксик на питоне и теперь руки чешутся запилить всякие ништяки на его основе, которые я врятли увижу в HC.

Можешь запилить эти ништяки на НС. Все для этого есть...
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #52 : 02 июня 2011, 20:40:12 »
>Можешь запилить эти ништяки на НС. Все для этого есть...

OK. Пошел разбираться...
Сообщить модератору   Записан
Страниц: 1 2 [3]  Все   Вверх
  Отправить эту тему    Печать  

« предыдущая тема следующая тема »
 
Перейти в:  



Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com