[ThreeDHead]

' timestamp='1322451339' post='659892']

Технически невозможно (с чем мы будем сравнивать файл, если его тело еще не загружено? а если мы загрузим тело, то сразу же уроним эффективность до 0%) - разве что делать надстройку над http, чтобы та сначала выкачивала хэш, сравнивала, а потом если и надо качала файл. но тогда придется модернизировать весь софт, который только имеется у абонента. Любое кэширование основано на допущениях "надеюсь юзер не заметит" и "ну уж этот-то сайт правильно отдает заголовки".

Вы невнимательно прочли:

1. Абонент запрашивает данные с удаленного сервера или сайта. Редиректор (маршрутизатор, коммутатор или устройство DPI) отправляет запрос в UltraBand кэш. Анализ файлового запроса основывается на информации содержащейся на 4 или 7 уровне запрашиваемых пакетов данных.

2. Сессия транслируется удаленному сайту или P2P клиенту без вмешательства UltraBand. Любые процедуры авторизации или отслеживание использования со стороны удаленного сайта проходят без изменений.

3. После того как удаленный узел принял решение о передаче объекта к абоненту, и началась передача, UltraBand проверяет объект. Если запрошенный файл существует в массиве хранения данных, то запрос на передачу файла с исходящего сервера/сайта останавливается.

4. UltraBand доставляет файл или объект абоненту абсолютно прозрачно - как будто из исходного сервера или сайта. Доставка содержимого осуществляется на физической скорости передачи данных внутри сети, предоставляя пользователю наилучшее качество опыта (quality of experience).

 

На самом деле, я уже примерно понимаю как у них устроен захват пакетов. Скорее всего на PBR, для iptables был написан модуль, который работает в ядре - в него-то и отправляются пакеты. Некий аналог коннекшн трекера, который может брать данные с кэша, а может тупо пропускать через себя. Идея не тянет на 300+ долларов.

 

А при использовании http-прокси, получаем один внешний айпишник со всеми вытекающими.

[[anp/hsw]]

А при использовании http-прокси, получаем один внешний айпишник со всеми вытекающими.

 

Добро пожаловать в мир squid+tproxy (уже как лет 7 в продакшене, года 2 как в mainline kernel). Это такие же басни из серии "открытые прокси юзают /dev/poll, и поэтому заткнутся на первой сотне запросов", и никого не волнует, что уже как 10 лет юзается epoll да kqueue.

 

Да и собственно не только со сквидом так - с любым прокси, с любым веб-сервером. как понадобилось - сделали. Опенсорс же.

Изменено 28 ноября, 2011 пользователем [anp/hsw]

[Ivan_83]

' timestamp='1322451339' post='659892']

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

 

Технически невозможно (с чем мы будем сравнивать файл, если его тело еще не загружено? а если мы загрузим тело, то сразу же уроним эффективность до 0%) - разве что делать надстройку над http, чтобы та сначала выкачивала хэш, сравнивала, а потом если и надо качала файл. но тогда придется модернизировать весь софт, который только имеется у абонента. Любое кэширование основано на допущениях "надеюсь юзер не заметит" и "ну уж этот-то сайт правильно отдает заголовки".

Прочитайте спецификации HTTP и хотя бы конфиг=доку от сквида.

 

Если сайт кривой, значит и юзерский кеш в браузере будет работать не правильно.

 

 

 

[replicant]

В общем, я так чувствую, ставить систему в центральной части России, где цены на магистральный трафик снижаются за год в 2 раза, смысла особого нет. По подсчетам, окупаемость системы стоимостью 200 000 долл. (6 млн в рублях) для провайдера средней руки около 4-5 лет.

 

PeerApp заявляет о реальной средней экономии полосы в 35%. При гигабитном канале экономия полосы составит 350 мбит или в наших текущих ценах около 190 тыс. руб. в месяц. В год это около 1,5 миллиона (потому как 450 тысяч нужно платить за техподдержку). То есть 4 года отбивки. С учетом снижения цен на полосу этот срок может увеличиться до 5-6 лет, потому как сейчас не очевиден профит от такой экономии полосы, а что будет с технологиями и трафиком через 5 лет вообще никто не скажет. Считаю, такие системы выгодны или при очень высоких ценах на каналы, или при больших объемах трафика (сети на несколько десятков или сотен тысяч абонентов).

 

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

 

Позволю заметить что 1 Гбит/с полосы стоит около 130 т.р. в месяц (можно найти даже за 100 т.р.), а 350 Мбит/с вообще всего 60-70 т.р., поэтому срок окупаемости системы можно смело увеличивать до 8-10 лет, что по сути в провайдинге = бесконечность. Овчинка выделки не стоит.

 

Считаю что надо изыскивать другие способы, а 6 млн.руб. потратить в модернизацию сети, серверов, замену оборудования и т.п., т.е. с умом и пользой.

[alex_001]

Кстати , а почему в в качестве opensource альтернативы всегда squid? Есть ведь http://trafficserver.apache.org - возможно с производительностью лучше будет.

[ThreeDHead]

Позволю заметить что 1 Гбит/с полосы стоит около 130 т.р. в месяц (можно найти даже за 100 т.р.), а 350 Мбит/с вообще всего 60-70 т.р., поэтому срок окупаемости системы можно смело увеличивать до 8-10 лет, что по сути в провайдинге = бесконечность. Овчинка выделки не стоит.

Позволю заметить что 1 Гбит/с полосы стоит более 2 млн. долл. в год, а есть места где еще дороже. Поэтому для начала прочтите ветку целиком, прежде чем рассуждать о необходимости подобной системы.

[Ivan_83]

Кстати , а почему в в качестве opensource альтернативы всегда squid? Есть ведь http://trafficserver.apache.org - возможно с производительностью лучше будет.

 

В топку апач, в nginx есть функционал для кеша.

 

 

 

[alex_001]

Кстати , а почему в в качестве opensource альтернативы всегда squid? Есть ведь http://trafficserver.apache.org - возможно с производительностью лучше будет.

 

В топку апач, в nginx есть функционал для кеша.

 

Это стёб ? В nginx - reverse proxy же без on-disk кэширования какого либо..

[nuclearcat]

nginx, apache плохо дружат с тем же HTTP 206

кеш там есть, но reverse proxy есть reverse proxy

[MMM]

Это стёб ? В nginx - reverse proxy же без on-disk кэширования какого либо..

В nginx есть proxy-cache, отлично работает.

 

для 206 есть трюк, когда заголовки Range отрезаются на nginx и файл заливается полностью.

но тут интересно иметь список URL (ютубы, вконтакты, музыка на одноклассниках итп), для которых выполнять такое кеширование

Изменено 29 ноября, 2011 пользователем MMM

[Ivan_83]

Всё там на диск пишется.

[alex_001]

http://www.scribd.com/doc/37301205/Apache-Traffic-Server-HTTP-Proxy-Server-on-the-Edge-Presentation - сравнение APS,Nginx,Sq... По реальной производительности правда ничего особо нет.

[replicant]

Позволю заметить что 1 Гбит/с полосы стоит около 130 т.р. в месяц (можно найти даже за 100 т.р.), а 350 Мбит/с вообще всего 60-70 т.р., поэтому срок окупаемости системы можно смело увеличивать до 8-10 лет, что по сути в провайдинге = бесконечность. Овчинка выделки не стоит.

Позволю заметить что 1 Гбит/с полосы стоит более 2 млн. долл. в год, а есть места где еще дороже. Поэтому для начала прочтите ветку целиком, прежде чем рассуждать о необходимости подобной системы.

 

Где 1 Гбит/с полосы стоит более 2 млн. долл. в год и более... Это что за место такое? Жесть какая-то. А какие у вас ценники для абонентов?

Изменено 29 ноября, 2011 пользователем replicant

[pppoetest]

Где, где... В Караганде. Ценники до 300 баксов за мбит >:(

[alexmern]

У нас покруче — сейчас $550 . Так что гигабит будет пол ляма в месяц.

http://uztelecom.uz/ru/press/news/2011/235/

[ThreeDHead]

У нас покруче — сейчас $550 . Так что гигабит будет пол ляма в месяц.

Вот он какой КазахТелеком, отыгривается не только на нас, но и на соседях. Да и соседский монополист, на своих тоже круто оттягивается. Уроды.

[replicant]

У нас покруче — сейчас $550 . Так что гигабит будет пол ляма в месяц.

http://uztelecom.uz/ru/press/news/2011/235/

Жесть!

[edo]

' timestamp='1322418353' post='659783']

Cache information for squid:

Hits as % of all requests: 5min: 31.6%, 60min: 33.3%

Hits as % of bytes sent: 5min: 2.7%, 60min: 3.4%

это с "честными" настройками?

[ThreeDHead]

' timestamp='1322418353' post='659783']

Cache information for squid:

Hits as % of all requests: 5min: 31.6%, 60min: 33.3%

Hits as % of bytes sent: 5min: 2.7%, 60min: 3.4%

2.7% попадания по трафику - экономия на спичках.

[ThreeDHead]

Cache information for squid:
       Request Hit Ratios:     5min: 72.2%, 60min: 70.1%
       Byte Hit Ratios:        5min: 72.2%, 60min: 67.8%
       Request Memory Hit Ratios:      5min: 40.7%, 60min: 36.4%
       Request Disk Hit Ratios:        5min: 41.0%, 60min: 46.3%

А вот попадания, так попадания ;)

[st_re]

2 ThreeDHead Все 4 человека посетили один сайт со статическим контентом ? ;)

[ThreeDHead]

2 ThreeDHead Все 4 человека посетили один сайт со статическим контентом ? ;)

Нет :) Мы начали кэшировать избранные направления. А конкретно, сервера статического контента (изображений) мейл.ру и их партнеров.

[st_re]

ааа.. И сколько отдано из кеша сквида ко всему вынутому из 80 порта ? Я так думаю даже меньше вышеназванных 3%, ибо туда попадается и еще что то, кроме мейлвру. И сколько 80 порта ко всему трафику ?

[ThreeDHead]

ааа.. И сколько отдано из кеша сквида ко всему вынутому из 80 порта ? Я так думаю даже меньше вышеназванных 3%, ибо туда попадается и еще что то, кроме мейлвру. И сколько 80 порта ко всему трафику ?

Ну естественно ;) Те-же 3%

[telematic]

Народ, а OverSI кто-нибудь юзает?