+  HandyCache форум
|-+  Главная категория» Новые предложения» Предложения по работе скриптов
Имя пользователя:
Пароль:
Страниц: 1 2 [3] 4  Все   Вниз
  Отправить эту тему    Печать  
Автор Тема: Предложения по работе скриптов  (Прочитано 41400 раз)
0 Пользователей и 1 Гость смотрят эту тему.
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #40 : 28 сентября 2008, 00:57:17 »

Цитировать
почему бы ничего не сравнивая посылать hc_header- измененный или нет неважно
Неважным это выглядит на первый взгляд. Если НС станет всегда манипулировать с заголовком даже если это и не нужно (а изменение заголовка не самая частая операция при использовании скриптов), это приведет к лишней нагрузке на машину (операции со строками являются относительно ресурсоемкими, они требуют выделения памяти, копирования содержимого с места на место).
Сообщить модератору   Записан
4water
Гость
« Ответ #41 : 28 сентября 2008, 01:37:44 »

Цитировать
Там и написано - в описании переменных hc_answer_body, hc_answer_header
там той информации что ты написал постом назад просто нет
Цитировать
А в чем вообще проблема? Так трудно присвоить значение "true" переменной hc_header_replace?
да
проблемно как-то это выглядит
изменил заголовок и могу надеяться что эти изменения заакцептятся ан нет- подтвердить дополнительно надо не забыть

и еще проблемно для восприятия выглядит hc_header и hc_answer_header
что будет если оба будут иметь значение?
можно б использовать hc_request_header и hc_answer_header- и не запутаешься и не пропадает информация о заголовке запроса
Цитировать
Неважным это выглядит на первый взгляд. Если НС станет всегда манипулировать с заголовком даже если это и не нужно (а изменение заголовка не самая частая операция при использовании скриптов), это приведет к лишней нагрузке на машину (операции со строками являются относительно ресурсоемкими, они требуют выделения памяти, копирования содержимого с места на место).
в свете того что нужно сравнить заголовок с исходным чтобы отразить это в мониторе это потребует каких-то затрат
но сравним их с затратами на исполнение сотен регэкспов- это ничто
взять даже заголовок 3 кБ что встретишь крайне редко (обычно до 1 кБ)
команда сравнения двух массивов типа CMPS ассемблера выполнится за столь ничтожное время что не успеет сработать даже один регэксп
а вот забыть присвоить переменной hc_header_replace значение это очень просто
да и просто ее наличие это дополнительная обуза
и неадекватно если заголовок не трогать, изменить hc_header_replace а монитор напишет что заголовок менялся

совершенно другое дело читать перед каждым скриптом кэш что сделано в новой версии
почему здесь не обратили внимание на затраты?
а они изрядные если используешь сетевой кэш
скорость работы программы замедляется на порядок и она превратилась в тормоз при 4 пользователях
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #42 : 28 сентября 2008, 02:35:12 »

4water
По поводу оправданности наличия переменной hc_header_replace не вижу особого смысла продолжать спор вот по какой причине. Доводы в пользу наличия или отсутствия этой переменной можно приводить долго, но не думаю, что одна из сторон сможет победить за явным преимуществом. Обсуждать этот вопрос имело бы смысл до того как НС в данной версии стал публичным. А на сегодня наличие переменной hc_header_replace стало фактом и для изменения этого положения должны быть веские причины.
Цитировать
совершенно другое дело читать перед каждым скриптом кэш что сделано в новой версии
почему здесь не обратили внимание на затраты?
а они изрядные если используешь сетевой кэш
скорость работы программы замедляется на порядок и она превратилась в тормоз при 4 пользователях
Согласен - проблема существует. Хотя краски в какой-то мере тобой сгущены. НС читает кэш, но не перед каждым вызовом скрипта, а только если на данный момент информация о нужном файле у него отсутствует. Однажды получив эту информацию (а она бывает нужна не только перед вызовом скрипта, но также при работе со списками и другими опциями), НС сохраняет ее в RAM-кэше и в дальнейшем берет ее оттуда.
В данном случае я буду благодарен тебе или кому угодно за хорошие предложения по смягчению проблемы.
В любом случае тебе спасибо за аргументированную критику.
« Последнее редактирование: 28 сентября 2008, 03:06:39 от mai62 » Сообщить модератору   Записан
4water
Гость
« Ответ #43 : 28 сентября 2008, 10:52:41 »

Цитировать
Обсуждать этот вопрос имело бы смысл до того как НС в данной версии стал публичным. А на сегодня наличие переменной hc_header_replace стало фактом и для изменения этого положения должны быть веские причины.
это бета
факта еще ни одного нет, все в руках создателя,можно и нужно пробовать все
если евыявляются неудобства почему бы не принять это в расчет и не ликвидировать их при наличии кворума
вопрос не высосан из пальца- я реально забываю присваивать эту переменную Улыбка
если hc_header_replace сейчас отменить то это реально не повлияет работу сущесьвующих скриптов
Цитировать
Хотя краски в какой-то мере тобой сгущены.
ну как сгущены- это очень сильно бросается в глаза мгновенная загрузка раньше и неспешная постепенная сейчас
не знаю может на какихто супер быстрых и незагруженных сетях это не так но на моем 100 мБит просто крах надежд интерсно увидеть еще отзывы о новой версии при использовании с сетевым кэшем, в форуме не смог увидеть?
пришлось с новой версией убирать дополнительный кэш и менять конфигурацию
мог бы и оставить старую версию но новые скрипты много хорошего дают
уже сам написал пару и доволен
Цитировать
В любом случае тебе спасибо за аргументированную критику.
те неудобства о которых писал с ними будет сталкиваться каждый
не хочу навязывать мнение но оно есть такое после начала реальной практики писания скриптов
если у остальных противоположные взгляды нестрашно я думаю может быть не безразличен любой взгляд со стороны

сейчас пишу скрипт и увидел что переменные которые иниции\ализировал в скрипте запроса не доживают до скрипта ответа
тоже неудобно прошу рассмотреть возможность сделать чтоб они жили все время существования запроса

еще прошу можно сделать чтобы не обязательно вводить e-mail при отправке поста
это типа hc_header_replace дополнительная и по моим ощущениям ненужная забота для юзвера

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

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

Сообщений: 5589



« Ответ #44 : 28 сентября 2008, 11:51:27 »

В данном случае я буду благодарен тебе или кому угодно за хорошие предложения по смягчению проблемы.

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

еще прошу можно сделать чтобы не обязательно вводить e-mail при отправке поста

Зарегистрируйся на форуме и этой проблемы не будет! Кроме того, скоро эта тема будет присоединена к параллельной: "Предложения по работе скриптов" в разделе "Новые предложения". Гостем ты писать там вообще не сможешь.
Сообщить модератору   Записан
4water
Гость
« Ответ #45 : 29 сентября 2008, 00:00:31 »

не удобно получается вставлять заголовки потому что hc_header оканчивается на \r\n\r\n
если сделать оканчивающийся на один \r\n то можно легко писать hc_header = hc_header .. "my header: my value\r\n"
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #46 : 29 сентября 2008, 10:18:09 »

не удобно получается вставлять заголовки потому что hc_header оканчивается на \r\n\r\n

Вообще-то это требование стандарта. Только не говори, что HC должен удалить двойной \r\n , а потом его опять вставить, чтобы тебе было проще писать скрипты...

Цитировать
если сделать оканчивающийся на один \r\n то можно легко писать hc_header = hc_header .. "my header: my value\r\n"

Сделай в скрипте замену: "\r\n\r\n" на "\r\nmy header: my value\r\n\r\n" - если так надо в конец добавить:
   string.gsub(hc_header, "\r\n\r\n", "\r\nMy header: my value\r\n\r\n", 1)

Вообще, можешь свои заголовки хоть сразу после первой строки вставлять.


P.S. А что там у тебя с регистрацией на форуме? Долго эта тема в Гостевом разделе жить не будет...
Сообщить модератору   Записан
4water
Гость
« Ответ #47 : 29 сентября 2008, 11:59:39 »

Цитировать
Вообще-то это требование стандарта.
такого быть не может
это просто так принял автор программы и мне кажется будет удобнее это чуть подправить
Цитировать
Только не говори, что HC должен удалить двойной \r\n , а потом его опять вставить, чтобы тебе было проще писать скрипты...
"должен" я не говорю думаю что уместно сказать "лучше", "удобнее пользователю" не только мне лично
оцени наглядность и удобство одного и второго
сравни также еще затраты (правда это мелочи)
мне вот интересно несет ли какой-то практический смысл передача hc_header сс двумя \r\n на конце? если этио для чего-то задумывалось то интересно услышать для чего а если просто так и никому не нужно то лучше так не передавать
Цитировать
Вообще, можешь свои заголовки хоть сразу после первой строки вставлять.
не вижу случаи когда это может понадобится но если вдруг понадобится сделаю именно так
Цитировать
А что там у тебя с регистрацией на форуме? Долго эта тема в Гостевом разделе жить не будет...
пока все также- никак
жду в этом разделе обещали помочь
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #48 : 29 сентября 2008, 16:59:52 »

Цитировать
Вообще-то это требование стандарта.
такого быть не может

Чего не может? RFC2616 почитай! После последнего заголовка должна быть пустая строка, иначе сервер будет ждать продолжения запроса.

Цитировать
"удобнее пользователю" не только мне лично

Лично мне без разницы! Скрипт пишется раз, а потом сам работает и внимания более не требует.
Затраты меньше сейчас, т.к. HC не надо лишний раз вырезать \r\n , а потом опять его добавлять.

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

А вставлять именно в конец - это что жизненная необходимость такая? Какая разница?
Сообщить модератору   Записан
4water
Пользователь
**

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

Сообщений: 51


« Ответ #49 : 29 сентября 2008, 17:32:42 »

спасибо большое что зарегистрили!

Цитировать
Чего не может? RFC2616 почитай! После последнего заголовка должна быть пустая строка, иначе сервер будет ждать продолжения запроса.
после заголовка должна быть но какое отношение это имеет к самому заголовку?
Цитировать
Затраты меньше сейчас, т.к. HC не надо лишний раз вырезать \r\n , а потом опять его добавлять.
gsub- каждый раз будет делаться поиск по шаблону, раздвижка строки и вставка
..- а так просто конкатенация
передаваться и приниматься программой юудет строка на 2 байт меньшая, все операции с ней в любом скрипте будут на 2 символа короче
отсюда и затрат меньше
Цитировать
А вставлять именно в конец - это что жизненная необходимость такая? Какая разница?
нет только ради простоты
если нет разницы в итоге, почему не делать проще?

еще нарвался на такое дело- это не страшно просто надо иметь ввиду делюсь наблюдением:
нельзя полагаться на то что переменные как везде в lua изначально равны nil
здесь получакется надо любую переменную или явно инициализировать или делать локальной потому что предыдущий скрипт мог оставить в ней все что угодно
« Последнее редактирование: 29 сентября 2008, 17:41:32 от 4water » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #50 : 29 сентября 2008, 19:37:35 »

Цель?
Например, для реализации предложения из ToDo:
Для исключения потерь времени при использовании в качестве родительского сжимающего сервиса типа WebWarper, Toonel, Cproxy добавить возможность создания условного родительского прокси, реагирующего на наличие/отсутствие на странице GZip-сжатия
Если файл в кэше не сжат, то запрос отправить, например, на Toonel или WebWarper.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #51 : 29 сентября 2008, 20:09:21 »

нельзя полагаться на то что переменные как везде в lua изначально равны nil
здесь получакется надо любую переменную или явно инициализировать или делать локальной потому что предыдущий скрипт мог оставить в ней все что угодно

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



Если файл в кэше не сжат, то запрос отправить, например, на Toonel или WebWarper.

А если сжат, то где гарантия, что он в предыдущий раз не грузился через WebWarper, поэтому и был им сжат?!
А если включена опция "Распаковывать gzip/deflate файлы перед записью в кэш", то все файлы в кэше будут не сжаты. Будем все грузить через Toonel без разбора?

Не, тут нужен другой подход - как у Проксомитрона: при получении несжатых данных писать имя сайта в файл-список, а при повторном заходе проверять этот список и принимать решение об использовании сжимающих серверов.
Сообщить модератору   Записан
4water
Пользователь
**

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

Сообщений: 51


« Ответ #52 : 29 сентября 2008, 22:00:56 »

Цитировать
Да, в этом есть и свои плюсы - можно значения переменных предыдущего скрипта использовать в следующем и сэкономить ресурсы на их повторной обработке. Ты же сам недавно предлагал вообще "рассмотреть возможность сделать чтоб они жили все время существования запроса"...
да я и не был против этого
во всех букварях по lua пишется что по умолчанию переменные равны nil
в скриптах так не будет дошел до этого собственным опытом в справке этого не было
пост написал для того чтобы поделиться с другими- чтоб не делались ошибки
можно и в справке это указать
а минусов этого вобще ни одного не вижу
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #53 : 29 сентября 2008, 22:15:04 »

в справке этого не было

Прям, как в поговорке: "Смотришь в книгу - видишь фигу!":
Цитировать
Если запускается несколько скриптов подряд, то очередному скрипту передаются глобальные переменные в том виде, в каком они остались после выполнения предыдущего скрипта.
Не первый раз уже. Может, стоит внимательнее читать Документацию?  Читай доки!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #54 : 29 сентября 2008, 22:30:37 »

А если включена опция "Распаковывать gzip/deflate файлы перед записью в кэш", то все файлы в кэше будут не сжаты. Будем все грузить через Toonel без разбора?
Хм... Ты думаешь, я как администратор не знаю, включена ли у меня такая опция или нет?
Цитировать
Не, тут нужен другой подход - как у Проксомитрона: при получении несжатых данных писать имя сайта в файл-список, а при повторном заходе проверять этот список и принимать решение об использовании сжимающих серверов.
Могу тоже подкинуть "если...". К примеру, что если этот файл захотят читать/менять одновременно несколько скриптов/потоков? Что если файл вырастет до сказочных размеров?
У такого подхода существенный недостаток - затратность.
То, что предлагаю, будет как часы и без каких-либо затрат работать как минимум с Тунелем.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #55 : 29 сентября 2008, 22:58:25 »

Хм... Ты думаешь, я как администратор не знаю, включена ли у меня такая опция или нет?

Хм... Я понимаю, что удобнее было ответить вопросом и причем только на вторую половину моего вопроса, но как все-таки быть со страницами, сжатыми ранее WebWarper-ом?
А что, переменная эта только для тебя создается? И те, кто распаковывает GZIP в кэше, не попадут в группу "избранных"?

Цитировать
То, что предлагаю, будет как часы и без каких-либо затрат работать как минимум с Тунелем.

Без каких-либо затрат? А выяснение атрибутов файла и типа сжатия с потолка возьмется, что ли?

Добавлено: 29 Сентября 2008, 23:52:43

Да и все равно, скрипты пока не умеют управлять "Внешними проксями".
« Последнее редактирование: 29 сентября 2008, 23:05:09 от DenZzz » Сообщить модератору   Записан
4water
Пользователь
**

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

Сообщений: 51


« Ответ #56 : 29 сентября 2008, 23:12:49 »

Цитировать
Прям, как в поговорке: "Смотришь в книгу - видишь фигу!":
правду говорят дурной пример заразителен
посмотрел я на тебя убеждавшего что там есть то чего нет- и тоже перестал тщательно справку читать
Цитировать
Не первый раз уже.
можешь смело обнулить счетчик Улыбка
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #57 : 30 сентября 2008, 00:05:39 »

Цитировать
Хм... Я понимаю, что удобнее было ответить вопросом и причем только на вторую половину моего вопроса, но как все-таки быть со страницами, сжатыми ранее WebWarper-ом?
Не готов к разговору о WebWarper и CProxy. Не пользую. Поэтому рецепта тебе подсказать не могу. Даже не могу сказать, будет ли он отличаться от рецепта для Тунеля.
Цитировать
А что, переменная эта только для тебя создается? И те, кто распаковывает GZIP в кэше, не попадут в группу "избранных"?
Хм... Чем-то повеяло почти забытым...
Пусть будут иметься в виду те, кто пользует Тунель и не распаковывает GZip в кэше. Ты думаешь, это буду я один?
А теперь представь себе другую "группу избранных", которым несущественны накладные расходы. И они готовы хоть с каждым запросом читать целиком большой файл, искать в нем запись, дописывать если не нашли и сохранять обратно. И все это непрерывно синхронизируя с остальными желающими равноправного доступа.
Цитировать
Без каких-либо затрат? А выяснение атрибутов файла и типа сжатия с потолка возьмется, что ли?
Это и так уже делается - читается Content-Type, а значит и все остальное. То, что я предлагаю, можно попробовать реализовать уже сейчас и без всяческих дополнительных затрат.
Цитировать
Да и все равно, скрипты пока не умеют управлять "Внешними проксями".
Это на первых порах можно попробовать перехитрить. А там и штатные средства поспеют.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #58 : 30 сентября 2008, 00:53:56 »

Пусть будут иметься в виду те, кто пользует Тунель и не распаковывает GZip в кэше. Ты думаешь, это буду я один?

А сколько вас? Кто считал? Не нужно опять возвращаться к аргументам типа: "Так лучше всем, я знаю!"...

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

Я так понимаю, что этот камень в огород Проксомитрона...

Цитировать
Цитировать
Да и все равно, скрипты пока не умеют управлять "Внешними проксями".
Это на первых порах можно попробовать перехитрить.

Каким образом "перехитрить"?
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #59 : 30 сентября 2008, 05:44:04 »

А сколько вас? Кто считал? Не нужно опять возвращаться к аргументам типа: "Так лучше всем, я знаю!"...
А сколько пользуют, к римеру, "Не загружать большие файлы", "Ограничить скорость загрузки", "Распаковывать перед записью в кэш" и т.д. и т.п.? Ты уверен, что все до одного пользователи? Или взять скрипт _block_external_links, думаешь, каждый его будет пользовать? Не достаточно ли того, что это будет заведомо многочисленный круг?
Цитировать
Каким образом "перехитрить"?
Пометить URL как-нибудь безобидно, а потом условным прокси эту пометку найти.
Сообщить модератору   Записан
Страниц: 1 2 [3] 4  Все   Вверх
  Отправить эту тему    Печать  

 
Перейти в: