On Tue, 27 Jul 2004, Михаил Монашёв wrote:
> softsearch.ru 30000 уников в сутки по счёткам. Спросите у Зенона кто у > меня в логах в поле юзер-агент записан и с какой частотой. Там > Гугл-бот, msn-бот, Яндекс, Гугл-Медиапартнёр. И они соспавляют > _основную_ нагрузку. При этом контент кэшируется Oops-ом. По запросам гугли вижу что их бот не принимает сжатый контент. Все остальные тоже? Экономят процессоры :) Печально. > IK> Не предусмотрено... Увы. На один урл приходится один документ. > > А разве это правильно? Кэшироваться должно всё на основании того, что Неправильно. Вернее так: правильно до тех пор, пока не нарушается поведение по RFC. Но не хорошо. С хранением разных версий одного документа есть проблемы 1. случай если ключем поиска является URL. Если хранится несколько версий документа то при поиске документа в кэше придется вернуть заголовки нескольких вариантов для того, что-бы выяснить, какой именно из вариантов отдать клиенту. 2. случай, если ключем поиска является url+значения каких-то заголовков. неясно что включать в этот ключ - ведь информация о том, какие заголовки были важны при отправке того или другого варианта документа хранятся в самом закэшированном документе, в заголовке Vary. Получается замкнутый круг. или опять-таки, вытягивать из кэша все варианты документа и анализировать их. вынимание нескольких вариантов из кэша - достаточно трудоемкая операция, особенно, когда документы лежат на диске. В старой версии храниение нескольких вариантов точно уже не будет реализовано. Относительно новой - я смогу это реализовать только в случае если станет ясно, как это можно сделать правильно и без большого ущерба для производительности. > езаписано в поле Vary. Это универсальный подход, частным случаем > которого является кэширование только по url. Как тогда кэшировать > скажем документы в разных кодировках, отдаваемы по одному url-у? Фактически так: модуль Vary добавляет в хранимый документ те значения полей запроса, по которым происходил content negotiation. При последующей отдаче эти поля просматриваются и принимаются соответствующие действия (либо перекодирование, либо запрос документа с сервера, если никакие действия не могут быть приняты). > Конечно, кодировки можно разнести на разные url-ы, тем самым создав > несколько зеркал одно сайта. А вот со сжатым контентом так не выходит > совсем, по разным url-ам не разнесёшь. > > >> сжимать контент акселем, потому как есть куча тонкостей, например баг > > IK> Логичнее - сделать так, что-бы не надо было ни сжимать, ни разжимать. Во всех > IK> прочих вариантах есть вероятность возникновения достаточно тяжелой нагрузки > IK> на процессор прокси. > > Полность согласен. Храня отдельно сжатый и несжатый контент, Да я тоже согласен. Только не знаю как это сделать правильно. > запрошенный по одному url-у мы получим небольшую нагрузку на Oops и > корректную работу со сжатым контентом. Дописать к url-у > контент-энкодинг и это урл исполльзовать для поиска в индексе. Конечно не только Content-Encoding. А Content-Type с charset? А вдруг еще какие-то (сегодня неизвестные, или известние только серверу) заголовки нужны серверу для выбора варианта? > там ещё проблему с куками и аутентификацией, но и это всё перодолимо. Ну документы с аутентификацией в кэше не хранятся, а документы с куками хранятся, но куки вырезаются при сохранениии в кэше (клиенту передаются только те куки, которые сервер посылает именно ему). > > С уважением, > Михаил Монашёв, 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 | PACO Links, igor at paco dot net | ===================================================================== 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/
