+  HandyCache форум
|-+  Главная категория» Дополнения, плагины» GE.lua - расширение HC для кэширование Google Earth
Имя пользователя:
Пароль:
Страниц: 1 2 3 [4] 5 6 ... 9   Вниз
  Отправить эту тему    Печать  
Автор Тема: GE.lua - расширение HC для кэширование Google Earth  (Прочитано 81362 раз)
0 Пользователей и 1 Гость смотрят эту тему.
mai62
Автор HC
*****

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

Сообщений: 6303


« Ответ #60 : 18 Июнь 2009, 16:37:31 »

Сейчас положу тебе в PM ссылку на исправленную версию, потестируй.
Сообщить модератору   Записан
Михаил
Модератор
*****

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

Сообщений: 5340



« Ответ #61 : 18 Июнь 2009, 19:41:29 »

Сервер Гугла отдает ответы HTTP 1.1 без Connection:close (по крайней мере, для 5-й версии), и значит, приложение GE их понимает. Если скрипт будет отдавать close, то последовательно создаст сотни соединений, хотя можно было обойтись двумя. А для GE 4-й версии какие ответы отдает сервер?

Может быть так, что именно из-за выявленной особенности POST-запроса все и происходит - соединение стопорится. А Connection: close просто не дает идти по одному соединению вслед за этим POST-запросом другим запросам. И поэтому по случайному стечению обстоятельств стало лекарством, временно устраняющим боль, но не лечащим причину.

Надо погонять скрипт без Connection: close на доработанном НС.
Сообщить модератору   Записан
Parasite
Пользователь
**

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

Сообщений: 66



« Ответ #62 : 19 Июнь 2009, 07:44:28 »

Сервер Гугла отдает ответы HTTP 1.1 без Connection:close
По дефолту коннекты ГЕ имеют статус Keep-Alive, и это явно светится на сниффере. Отсутствие прямого указания есть распространенная ошибка при работе с ГЕ - его от этого глючит. Проверено лично и не раз. Вот типичный заголовок ответа сервера:

Код:
header('HTTP/1.1 200 OK');
header('Content-Type: application/octet-stream');
header('Expires: 0');
header('Cache-Control: no-cache,no-store');
header('Set-Cookie: PREF=ID=ce13d9b0466f4e82:TM=1240495121:LM=1240495121:S=PaQRO6QQesvvAwz5; expires=Sat, 23-Apr-2011 13:58:41 GMT; path=/; domain=.google.com');
header('Date: '.date("D, d M Y G:i:s").' GMT');
header('Server: btfe');
header('Content-Length:'.strlen($content));
header('Connection: Keep-Alive');
header('Keep-Alive: 300');
header('');

, где для клиента обязательными для рассмотрения являются поля

Код:
header('HTTP/1.0 200 OK');
header('Content-Type: application/octet-stream');
header('Content-Length:'.strlen($content));
header('Connection: Keep-Alive');
header('');

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

Если скрипт будет отдавать close, то последовательно создаст сотни соединений, хотя можно было обойтись двумя.
Дело в том, что при работе ГЕ в штатном режиме как раз и создаются сотни соединений, а Keep-Alive нужен для ОДНОЗНАЧНОГО указания клиенту, как поступать с уже открытыми. Что же касается именно сотен - так ГЕ одновременно не открывает больше 10 соединений за раз (лично я не видел и 10и, обычно 3-5), и при этих "подвисших" 10и соединениях получаем тормоза клиента при отправке новых запросов.

Да, и со стороны сервера ГЕ коннекты Keep-Alive по которым уже прошла передача данных - сбрасываются гораздо быстрее указанных 300 секунд, навскидку секунд за 20-30 - что и имело место быть при глюке, описанном в первом посте этой ветки.

Клиенту ГЕ надо прямо указывать, что делать с коннектами - либо Keep-Alive на время X (и тогда оно отобьется сервером много ранее), либо Close - и тогда оно отобьется клиентом намного быстрее.

А для GE 4-й версии какие ответы отдает сервер?
Точно те же - сервер-то тот же.

Может быть так, что именно из-за выявленной особенности POST-запроса все и происходит - соединение стопорится. А Connection: close просто не дает идти по одному соединению вслед за этим POST-запросом другим запросам. И поэтому по случайному стечению обстоятельств стало лекарством, временно устраняющим боль, но не лечащим причину.
Нет.
Сделайте скрипт, который запрашивает на ГЕ например /geauth, но не указывает состояния коннекта. Получите практически мгновенный контент, но вот скрипт будет ждать закрытия соединения еще секунд 20-30. При указании Close - мгновенный выход после окончания передачи контента. Проверено - у меня есть самописный аналог сервера ГЕ, написанный на Перле плюс Апач (для коего собственно контент и нарабатывается при помощи HC), выдержки из которого я и привел выше. Улыбка С заголовками в свое время я поплясал долго и нудно.....Однозначное указание состояния коннекта является ОБЯЗАТЕЛЬНЫМ при работе с ГЕ, особенно если при работе без оных появляются глюки с медленными запросами. При быстром же коннекте (например в локалке) Close и вовсе рекомендовано лучшими собаководами нашего городка. Улыбка
Добавлено: 19 Июня 2009, 07:41:20

Сейчас положу тебе в PM ссылку на исправленную версию, потестируй.
Всю ночь работали 4 ГЕ разных версий с 4х компьютеров. 8.5млн запросов в сумме.....НИ ОДНОГО вылезшего ГЕ. Браво, так держать!!! Улыбка
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #63 : 19 Июнь 2009, 12:33:26 »

Сделайте скрипт, который запрашивает на ГЕ например /geauth, но не указывает состояния коннекта. Получите практически мгновенный контент, но вот скрипт будет ждать закрытия соединения еще секунд 20-30.

А ты напиши скрипт, который не ждет закрытия соединения, а посылает по нему следом второй запрос, третий и т.д. В итоге сэкономишь время на открытие новых соединений.
Кроме того, раз сервер ГЕ поддерживает HTTP/1.1, то он должен и pipelining понимать, а это значит, что ты можешь скриптом заслать серверу по одному соединению конвейером группу запросов, а потом принимать последовательно на них ответы. Опять же, сэкономишь время на организацию соединений и сократишь очередь на их обработку на сервере.

Однозначное указание состояния коннекта является ОБЯЗАТЕЛЬНЫМ при работе с ГЕ, особенно если при работе без оных появляются глюки с медленными запросами.

Если все так плохо у ГЕ с keep-alive, почему же они до сих пор не пофиксят этот баг?
Почему ГЕ-клиент не использует (по твоим утверждениям) открытое keep-alive соединение повторно (хотя в твоем логе я вижу обратное)?
И почему описанную проблему испытывают не все пользователи ГЕ?
« Последнее редактирование: 19 Июнь 2009, 12:46:35 от DenZzz » Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6303


« Ответ #64 : 19 Июнь 2009, 13:07:18 »

Цитировать
Кроме того, раз сервер ГЕ поддерживает HTTP/1.1, то он должен и pipelining понимать
Они ведь не общедоступный сервер сделали, насколько я понимаю. Они для доступа к нему сами делают своих клиентов. Поэтому вполне могут наплевать на стандарты и сделать как им нравится.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #65 : 19 Июнь 2009, 13:32:06 »

Они ведь не общедоступный сервер сделали, насколько я понимаю. Они для доступа к нему сами делают своих клиентов. Поэтому вполне могут наплевать на стандарты и сделать как им нравится.

Они должны учитывать, что между их клиентом и сервером может быть куча прокси-серверов посредников, которые поддерживают все требования стандартов и могут сами сгруппировать запросы пачками и применить конвейер, т.к. сервер ГЕ назвался HTTP/1.1 сервером.

Ну, бог с ним, с pipelining-ом. Речь сейчас про keep-alive. В логе выше от Parasite я насчитал 21 запрос от ГЕ-клиента по одному соединению # 56, а это означает, что keep-alive клиент ГЕ понимает и очень даже активно его использует!

P.S. Где-то раньше я проводил замеры времени с использованием keep-alive и без - получалось, что из кэша HC без keep-alive страницы с множеством элементов загружаются почти в 2 раза медленнее, чем с keep-alive, поэтому менять в скрипте keep-alive на close выйдет весьма накладно...
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6303


« Ответ #66 : 19 Июнь 2009, 13:47:41 »

Цитировать
Они должны учитывать, что между их клиентом и сервером может быть куча прокси-серверов посредников, которые поддерживают все требования стандартов и могут сами сгруппировать запросы пачками и применить конвейер, т.к. сервер ГЕ назвался HTTP/1.1 сервером.
Должны, не должны не знаю. Они сделали причудливое объединение файлов в группы при закачке, которое исключает их кэширование стандартными прокси-серверами. Это же их не смутило. Кстати объединение нескольких запросов в один компенсирует потери от неиспользования keep-alive (если они его не используют, я не проверял).
Цитировать
Где-то раньше я проводил замеры времени с использованием keep-alive и без - получалось, что из кэша HC без keep-alive страницы с множеством элементов загружаются почти в 2 раза медленнее, чем с keep-alive, поэтому менять в скрипте keep-alive на close выйдет весьма накладно...
У меня нет сомнений в полезности использования keep-alive. Я просто думаю, что если они так хотят, они могут его не использовать. Их ведь, богатых, не поймешь.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #67 : 19 Июнь 2009, 14:02:27 »

Кстати объединение нескольких запросов в один компенсирует потери от неиспользования keep-alive (если они его не используют, я не проверял).

Посмотри в логе выше. ГЕ-клиент использует keep-alive, причем весьма активно!
Если бы Parasite не вставил в скрипт принудительный close, то запросов через активные keep-alive соединения было бы еще больше!
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6303


« Ответ #68 : 19 Июнь 2009, 14:16:35 »

Цитировать
ГЕ-клиент использует keep-alive, причем весьма активно!
Пусть использует. Лишь бы из-за этого сбоев не возникало.
Сообщить модератору   Записан
Parasite
Пользователь
**

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

Сообщений: 66



« Ответ #69 : 19 Июнь 2009, 14:30:44 »

А ты напиши скрипт, который не ждет закрытия соединения, а посылает по нему следом второй запрос, третий и т.д.
А зачем, если всё прекрасно работает уже сейчас? Улыбка

Более того, на момент моего плотного ковыряния ГЕ сервер не позволял несколько запросов в одном соединении (проверялось), да и сейчас последняя версия ГЕ предпочитает посылать не три последовательных запроса, а ОДИН запрос на связку трех тайлов в виде ОДНОГО файла в каждом соединении, кой файл позже и разбирает (что жрет ненулевые ресурсы на обоих сторонах коннекта).
Не спрашивайте меня, почему у них в заголовках именно Keep-Alive - я этого не знаю. Возможно, это фича связана с QT-based приложениями (GE - одно из них). Не знаю, врать не буду. Работает, почти не глючит - и Аллах с ним.

В итоге сэкономишь время на открытие новых соединений.
Открытие новых соединений в случае с локалкой - несущественно, а в случае с интернетом - собственно контент передается много дольше и разово (в случае с HC и кэшированием), так что это тоже не бутылочное горлышко.
Бутылочное горлышко в случае ГЕ - это необходимость наличия валидных сессий и постоянные переавторизации в связи с этим. В случае же ГМ (GoogleMaps) - это еще и лимит на количество запросов на сервер за единицу времени, превысил - получи бан на сутки-двое-несколько. Так что широкоупотребимая хохма "Тебя что, на гугле забанили??" таки иногда имеет место быть. Грустный

Если все так плохо у ГЕ с keep-alive, почему же они до сих пор не пофиксят этот баг?
Наверное потому, что это не баг а фича. Возможно, оно таки где-то в какой-то части работы используется, либо планируется использовать, либо гуглевцам хочется видеть работу с клиентом это именно так, а не иначе.

И почему описанную проблему испытывают не все пользователи ГЕ?
Потому что в заголовках родного сервера ГЕ есть прямое указание насчет состояния коннекта, а в HC+GE.lua его не было.

Это спор ни о чем. Предлагаю закруглиться. Подредактированный скрипт проблем на наст.время у меня лично не вызывает, в отличие от его первоначального вида, доставлявшего некоторые проблемки. Он работает, как и задумывался (спасибо автору за него!!). Если кому-то из юзеров не понравится вывод "Connection:Close" в хидеры - они вполне смогут либо обосновать это тут, либо вынести самостоятельно. Предлагаю все же оставить этот вывод в скрипте на будущее, ибо как минимум в моем лице это зело помогло уйти от траблов, и автор приобрел еще одного пользователя. Решать, конечно же - автору.

Да, и в моем Перле тоже есть строки:
Код:
$fp = fsockopen("kh.google.com", 80, $errno, $errstr, 15);
...<skip>...
$out .= "Content-Length: ".strlen($data)."\r\n";
$out .= "Connection: Close\r\n";
$out .= "\r\n";
fwrite($fp, $out);
...и это тоже прекрасно работает so far. Улыбка

Можем ли мы перейти к обсуждению пунктика сортировки контента средствами самого скрипта? Спасибо.

Где-то раньше я проводил замеры времени с использованием keep-alive и без - получалось, что из кэша HC без keep-alive страницы с множеством элементов загружаются почти в 2 раза медленнее, чем с keep-alive, поэтому менять в скрипте keep-alive на close выйдет весьма накладно...
Дело не в замене Keep-Alive на Close в скрипте. Дело в том, что в ПЕРВОНАЧАЛЬНОМ скрипте вообще не было никакого указания - ни Keep-Alive, ни Close, и это и была ошибка.

Попробуйте поменять в скрипте на Keep-Alive - оно должно тоже работать. Я не пробовал. Скрипт-то отдает этот параметр в сторону клиента ГЕ, а не в сторону интернет-сервера (как я понимаю), а клиент ГЕ как правило на той же машине либо, в худшем случае - в той же локалке. То есть, при скорости loopback\LAN потери таки мизерны.

« Последнее редактирование: 19 Июнь 2009, 14:45:25 от Parasite » Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6303


« Ответ #70 : 19 Июнь 2009, 14:34:26 »

Цитировать
Можем ли мы перейти к обсуждению пунктика сортировки контента средствами самого скрипта?
Работа над такой возможностью для НС ведется. Будет что попробовать сообщу.
Сообщить модератору   Записан
Parasite
Пользователь
**

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

Сообщений: 66



« Ответ #71 : 19 Июнь 2009, 14:41:59 »

Цитировать
Можем ли мы перейти к обсуждению пунктика сортировки контента средствами самого скрипта?
Работа над такой возможностью для НС ведется. Будет что попробовать сообщу.
То есть, пока что сортировать контент именно скриптом не представляется возможным? Я правильно понял?
На мой взгляд, вопрос (для HC) заключается в том, что от скриптов надо бы принимать относительные пути для сохранения в кэше относительно корня оного, если HC еще этого не умеет. А уж посчитать путь в самом скрипте и перекрыть стандартный HCшный путь - дело техники, имхо, если HC принимает подобные перекрытия от расширений.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #72 : 19 Июнь 2009, 15:04:03 »

Дело не в замене Keep-Alive на Close в скрипте. Дело в том, что в ПЕРВОНАЧАЛЬНОМ скрипте вообще не было никакого указания - ни Keep-Alive, ни Close, и это и была ошибка.

Согласно RFC 2616 отсутствие заголовка "Connection:" в HTTP/1.1 приравнивается к "Connection: Keep-Alive". Неужели ГЕ-клиент об этом не знает?
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6303


« Ответ #73 : 19 Июнь 2009, 15:09:11 »

Ты правильно понял. Сейчас нельзя, хочу сделать чтобы можно было. Внешне будет выглядеть примерно так как ты описал.
Сообщить модератору   Записан
zed
Постоялец
***

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

Сообщений: 135


WWW
« Ответ #74 : 19 Июнь 2009, 16:16:23 »

Цитировать
Просьба попробовавшим скрипт - отписаться, всё ли ОК с клиентом.
Подтверждаю, с новым скриптом гугл перестал зависать. 
Сообщить модератору   Записан
Parasite
Пользователь
**

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

Сообщений: 66



« Ответ #75 : 19 Июнь 2009, 18:38:32 »

Согласно RFC 2616 отсутствие заголовка "Connection:" в HTTP/1.1 приравнивается к "Connection: Keep-Alive".
Так то в RFC2616, а то - в коммуникации между закрытым продуктом "Google Earth" и столь же закрытым сервером "Base Thumbnail Front End". Улыбка

PS: ГЕ вообще не гуглевая разработка, причем весьма старая - ждать от нее полной поддержки HTTP1.1 (которого на момент разработки просто не было) имхо было бы несколько опрометчиво. Со своей же стороны гуглеребята, скорее всего, просто забили на это - и ведь действительно, РАБОТАЕТ. Улыбка

Могу выложить сетапчик GoogleEarth в состоянии "еще задолго до Гугля", если кому интересно. Улыбка
Сообщить модератору   Записан
Михаил
Модератор
*****

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

Сообщений: 5340



« Ответ #76 : 19 Июнь 2009, 18:40:00 »

Цитировать
Дело в том, что в ПЕРВОНАЧАЛЬНОМ скрипте вообще не было никакого указания - ни Keep-Alive, ни Close, и это и была ошибка.
Это не ошибка. Как уже отметил DenZzz - это правильное поведение в соответветствии со стандартом. Гугл об этом знает: от сервера GE ответы приходят без Connection: keep-alive.
Думаю, первоначальный скрипт правилен. А все проблемы исходили только от неправильного запроса POST. Parasite, проверь это, плиз, в своих сложных условиях.
Сообщить модератору   Записан
Parasite
Пользователь
**

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

Сообщений: 66



« Ответ #77 : 19 Июнь 2009, 19:01:27 »

Ты правильно понял. Сейчас нельзя, хочу сделать чтобы можно было. Внешне будет выглядеть примерно так как ты описал.
Подождем. Спасибо.

Это не ошибка. Как уже отметил DenZzz - это правильное поведение в соответветствии со стандартом. Гугл об этом знает: от сервера GE ответы приходят без Connection: keep-alive.
Тем не менее, это безусловно РАБОТАЕТ у двух юзеров, у которых ранее были проблемы.
Скрин с Wiresharka (с Keep-Alive) - тут: http://narod.ru/disk/10048509000/Clipboard02.gif.html
« Последнее редактирование: 19 Июнь 2009, 19:29:16 от Parasite » Сообщить модератору   Записан
Михаил
Модератор
*****

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

Сообщений: 5340



« Ответ #78 : 19 Июнь 2009, 19:26:57 »

Прилагаю аттач с WireShark'а
Мы ж об ответах говорим, а тут запрос...
Сообщить модератору   Записан
Parasite
Пользователь
**

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

Сообщений: 66



« Ответ #79 : 19 Июнь 2009, 19:35:27 »

Мы ж об ответах говорим
А как ведет себя HC (в виде сервера) при входящем Keep-Alive с клиента и наличии всех тайлов в кэше, и без последующего принудительного дропа? Контент HC отдал под запрос - ок, а дальше что? Дропать-то соединение кто будет - HC по таймауту? У гугля-то дропается сервером, и весьма быстро. Улыбка
Сообщить модератору   Записан
Страниц: 1 2 3 [4] 5 6 ... 9   Вверх
  Отправить эту тему    Печать  

 
Перейти в: