Здравствуйте Игорь,

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

softsearch.ru 30000 уников в сутки по счёткам. Спросите у Зенона кто у
меня  в  логах  в  поле  юзер-агент  записан  и  с какой частотой. Там
Гугл-бот,   msn-бот,   Яндекс,  Гугл-Медиапартнёр.  И  они  соспавляют
_основную_ нагрузку. При этом контент кэшируется Oops-ом.

IK> На момент выбора этой стратегии положение было такое: мало серверов отдавали
IK> сжатый контент и много клиентов понимали сжатый контент. В этой ситуации
IK> (с учетом того, что oops не может хранить два варианта документа с одним URL)
IK> оптимально - приняв сжатый контент не разжимать его. Тенденция к росту числа
IK> серверов, отдающих сжатый контент, только улучшает ситуацию.

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

>> Подобное  чревато  тем, что разжимание съест все ресурсы. Логично было

IK> Фактически, с этим проблем не видно.

>> бы  отдельно  кэшировать  сжаты  и  несжатый  контент.  А ещё логичнее

IK> Не предусмотрено... Увы. На один урл приходится один документ.

А  разве это правильно? Кэшироваться должно всё на основании того, что
езаписано  в  поле  Vary.  Это  универсальный  подход, частным случаем
которого  является  кэширование  только  по  url. Как тогда кэшировать
скажем  документы  в  разных  кодировках,  отдаваемы  по одному url-у?
Конечно,  кодировки  можно  разнести на разные url-ы, тем самым создав
несколько  зеркал одно сайта. А вот со сжатым контентом так не выходит
совсем, по разным url-ам не разнесёшь.

>> сжимать  контент акселем, потому как есть куча тонкостей, например баг

IK> Логичнее - сделать так, что-бы не надо было ни сжимать, ни разжимать. Во всех
IK> прочих вариантах есть вероятность возникновения достаточно тяжелой нагрузки
IK> на процессор прокси.

Полность   согласен.   Храня   отдельно  сжатый  и  несжатый  контент,
запрошенный  по  одному  url-у мы получим небольшую нагрузку на Oops и
корректную    работу   со   сжатым   контентом.   Дописать   к   url-у
контент-энкодинг и это урл исполльзовать для поиска в индексе. Конечно
там ещё проблему с куками и аутентификацией, но и это всё перодолимо.

С уважением,
Михаил Монашёв, SoftSearch.ru
Member of Independent Software Developers Forum (ISDEF)
mailto:[EMAIL PROTECTED]
ICQ# 166233339
http://softsearch.ru/
Без бэкапа по жизни.


=====================================================================
If you would like to unsubscribe from this list send message to
[EMAIL PROTECTED] with "unsubscribe oops" in message body.
Archive is accessible on http://lists.paco.net/oops-rus/
  • ... Михаил Монашёв
    • ... Igor Khasilev
      • ... Михаил Монашёв
        • ... Dmitry Ishutkin
        • ... Igor Khasilev
          • ... Михаил Монашёв
            • ... Igor Khasilev
              • ... Михаил Монашёв
                • ... Igor Khasilev
            • ... Pavel Prikhodko
              • ... Dmitry Alyabyev
              • ... Vladimir Sharun

Дати відповідь електронним листом