Перейти к содержимому
Калькуляторы

если есть локальный кэш y-tube - стоит ли заморачиваться еще и на Мару ? Т.е. решив проблему по 60%-70% трафика в ЧНН, стоит ли дожимать мелочь за совсем не детские деньги ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если есть локальный кэш y-tube - стоит ли заморачиваться еще и на Мару ?

 

Стоит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У мары есть большая проблема - больные на голову продажники.

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

А еще был очень неприятный инцидент, один из клиентов по истечению подписки Мару отложил в сторону и поставил себе на тест другой кеш engine. Потом решил включить оба, оплатил подписку. И сюрприз, они посчитали время подписки не с момента оплаты, а с момента истечения, т.е. взяли деньги за неоказанную услугу.

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

 

Поэтому если я смотрю, то на Bluecoat, но он весьма недешев и это для клиентов у кого много денег, и новый вендор на рынке - thundercache, который уже неплохо работает(+ активно развивается в отличии от мары), продается как софт и вроде как дешевле, оплата ежемесячно и очень гибко.

http://bmsoftware.org/index.php/en/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У мары есть большая проблема - больные на голову продажники.

 

Мне, видимо, повезло.

Со мной общается очень вменяемый человек.

 

И сюрприз, они посчитали время подписки не с момента оплаты, а с момента истечения,

 

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

У Пираппа или Аллота, не помню уже, были точно такие-же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скорее всего, есть такой ценник на канал, что лучше честно докупить полосы, чем слегка мухлевать? <15$ за 1Мб/c ? <30$ ? <50$ ?

Изменено пользователем Azamat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Извиняюсь, что отвечаю на вопрос, заданный не мне.

Редирект на кэш производится средствами WCCP на роутере.

 

Спасибо, то бишь выходит транспарент прокси?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скорее всего, есть такой ценник на канал, что лучше честно докупить полосы, чем слегка мухлевать? <15$ за 1Мб/c ? <30$ ? <50$ ?

 

В нашей деревне очень глупое ценообразование. Нужно преодолеть барьер из очень дорогих первых 100 Мбит, точнее 2x100 взятых у двух независимых поставщиков. Затем цена ненормально быстро падает при увеличении объема от 200 до гига. Больше гига тут никто не юзает даже среди кабельных, не говоря уже о беспроводных. Так что при маленьких скоростях кешилки выходят слишком дорого, при больших - расширение каналов выгоднее.

 

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

 

Мне интересно, чудики подписываются под каким либо SLA? Ну если завтра Facebook введет раздачу контента по https или гугл заскремблирует свои кеши - они вернут деньги за годовую подписку?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, то бишь выходит транспарент прокси?

Да, девайс по http прозрачен для юзера.

Что касается P2P, то он выступает локальным пиром.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мне интересно, чудики подписываются под каким либо SLA? Ну если завтра Facebook введет раздачу контента по https или гугл заскремблирует свои кеши - они вернут деньги за годовую подписку?

Фейсбук УЖЕ перешел на https, и по крайней мере в Ливане отчаянно сосем бамбук и провайдеры воют из-за перегруженных https-ом с facebook/akamai каналов. Осталась порнушка, youtube, apple/windows updates.

 

Кстати, у мары кеширование не совсем уж прозрачное, если у вас будет не-HTTP ресурс на 80-м порту (например War Commander, флеш игрушка), то оно работать не будет, какая-то фишка у Мары была в стадии BETA, но я с ней наловил кучу глюков и выключил. На Bluecoat в большинстве случаев bypass отрабатывает автоматически, но в редких случаях приходится добавлять вручную.

 

Еще в так сказать "OPEX" нужно добавлять периодически высыпающиеся SSD и винты. SSD по исчерпанию ресурса, они там работают в тяжелом режиме (живут от полугода до двух лет), а HDD если высоко-RPMные сами по себе мрут часто.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, по WCCP v2 работает железка. У нас нет никаких проблем с кешированием, наоборот, как только выключаем кеширование, клиенты начинают выть, а что так ютуб плохо грузит)). Был загон с торрент трекером, работающим не по 80 порту, но после пары писем все успешно решилось в течении 2-х дней.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто-нибудь поднимал кэш на Apache Traffic Server? Больше всего интересует настройка WCCP. Выбор пал именно на него по причине того, что Squid не справляется с 700мб веб-трафика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коллеги, кто-нибудь использовал в работе решение DiviNetworks ?

Имеем от них предложение, пока не принимаем никаких решений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если есть локальный кэш y-tube - стоит ли заморачиваться еще и на Мару ?

Стоит.

 

Смысл?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если кто-то стоит перед выбором системы кэширования, то обязательно проведите следующий тест (если оно у вас на тесте):

 

for SEQ in `seq 1 100`; do echo $SEQ; time curl -s http://local.site/test.png >/dev/null; sleep 1; done

 

Произвести запуск скрипта, с заворотом через систему кеширования.

И повторный запуск, без заворота через систему кеширования.

 

Вот пример работы PeerApp:

 

  • Без UB - min:11, max:14, avg:11.06
  • С UB (первая попытка) - min:8, max:41, avg:21.52
  • С UB (вторая попытка) - min:9, max:104, avg:28.14

 

Что видим:

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

Но вот уже отдача с кеша, начинает приносить неприятности. Нету стабильно быстрой отдачи контента. Что при использовании выливается в какую-то "вязкость" в получении контента.

 

И, конечно, хотелось бы увидеть результаты этого теста, на других системах кеширования.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, у кого-нибудь Р2Р кэширование на Кошмаре взлетело?

Да, проднялось нормально. Надо настраивать локальный DNS. Документация нечеткая, немного помогла переписка.

Правила такие:

1. Клиенты должны резольдиться (обратным запросом) в домен local. или в ваш домен.

2. Создать запись A для кашмары, интерфейс для P2P (в домене local или в своем домене, local лучше).

2. В домене клиентов надо создать указатель на службу TCP:55551:bittorrent-tracker (имя сервера - то что сделали в п2 , IP не пойдет).

_bittorrent-tracker._tcp 600 IN SRV 0 10 55551 retracker.local. (имя произвольное, главное чтобы была нужная запись в DNS и ссылалась на P2P интерфейс кашмары).

3. Если клиенты резольдятся в разные домены, то повторить п3 в каждом. В {Сетевые установки/Сетевые утилиты} можно проверить для конкретного IP клиента.

4. Клиенты по протоколу BitTorrent Local Tracker Discovery Protocol находят трекер (кашмару), лезут на него с анонсами.

5. Кашмара начинает скачивать в свой кеш если несколько клиентов "стукнулись" с одним и тем же хеш-инфо.

6. Если разрешить кашмаре скачивать с Тырнета, то скачивает когда нечего скачивать от клиентов. Ну и выпустить в Тырнет надо IP интерфейса P2P.

 

Рекомендую ограничивать скорость отдачи. Иначе сильно нагружает диск.

 

Мы попробовали, все получилось ... и отказались. Слишком диск нагружается, начинает проседать HTTP трафик. 8хSAS винтов не успевают и HTTP и P2P кеш обслуживать.

HTTP более приоритетное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нету стабильно быстрой отдачи контента. Что при использовании выливается в какую-то "вязкость" в получении контента.

Имеете ввиду относительные min/max?

Думаю, это неизбежно. Даже при пинге такое наблюдается.

Например, пингую 8.8.8.8 - получаю 120-130 мс. Относительная девиация получается несколько процентов.

Пингую соседний ПК, получаю 1-2 мс, относительная девиация 50-100%%.

 

ИМХО, главное что средняя скорость на много больше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имеете ввиду относительные min/max?

Думаю, это неизбежно. Даже при пинге такое наблюдается.

Например, пингую 8.8.8.8 - получаю 120-130 мс. Относительная девиация получается несколько процентов.

Пингую соседний ПК, получаю 1-2 мс, относительная девиация 50-100%%.

 

ИМХО, главное что средняя скорость на много больше.

 

Я прокомментирую (в цифрах время загрузки изображения, в мс):

  • Без UB (в чистую) - min:11, max:14, avg:11.06 <--- Лучший результат
  • С UB (первая попытка) - min:8, max:41, avg:21.52 <--- Плохой результат
  • С UB (вторая попытка) - min:9, max:104, avg:28.14 <--- Ужасный результат

Пинг не в тему. Речь о _локальном_ ресурсе, до него пинг 1мс всегда.

Про неизбежность тоже. Это когда с памятью разработчики работать не умеют, тогда да, неизбежно.

Изменено пользователем ThreeDHead

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, у кого-нибудь Р2Р кэширование на Кошмаре взлетело?

Да, проднялось нормально. Надо настраивать локальный DNS. Документация нечеткая, немного помогла переписка.

Правила такие:

1. Клиенты должны резольдиться (обратным запросом) в домен local. или в ваш домен.

2. Создать запись A для кашмары, интерфейс для P2P (в домене local или в своем домене, local лучше).

2. В домене клиентов надо создать указатель на службу TCP:55551:bittorrent-tracker (имя сервера - то что сделали в п2 , IP не пойдет).

_bittorrent-tracker._tcp 600 IN SRV 0 10 55551 retracker.local. (имя произвольное, главное чтобы была нужная запись в DNS и ссылалась на P2P интерфейс кашмары).

3. Если клиенты резольдятся в разные домены, то повторить п3 в каждом. В {Сетевые установки/Сетевые утилиты} можно проверить для конкретного IP клиента.

4. Клиенты по протоколу BitTorrent Local Tracker Discovery Protocol находят трекер (кашмару), лезут на него с анонсами.

...

 

Это стандартная фича torrent протокола Bep 22. В принципе достаточно включить и настроить ретрекер чтобы получать профит от этого. Кеширование p2p уже опционально.

 

Нюансы тут: http://forum.nag.ru/forum/index.php?showtopic=47615&st=480

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я прокомментирую (в цифрах время загрузки изображения, в мс):

Без UB (в чистую) - min:11, max:14, avg:11.06 <--- Лучший результат

С UB (первая попытка) - min:8, max:41, avg:21.52 <--- Плохой результат

С UB (вторая попытка) - min:9, max:104, avg:28.14 <--- Ужасный результат

Упс... На цифры не посмотрел внимательно.

Но думаю, учитывая "мс", вполне понятно.

Отключите логирование и прочие посторонние задачи и наверное получите примерно то-же время загрузки через кеш. А может даже немного больше (т.е. хуже).

ИМХО, любое промежуточное звено будет вносить свою задержку.

Прогоните тот же тест с более удаленным сервером, результаты будут существенно лучше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати у DPI Скат вроде указана возможность кэширования, кто-нибудь эксперементировал? цену за месяц лицензии они небольшую просят, если позволит экономить 15-30% полосы, будет просто прекрасно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отключите логирование и прочие посторонние задачи и наверное получите примерно то-же время загрузки через кеш. А может даже немного больше (т.е. хуже).

Вы специалист поддержки PeerApp'а или владелец системы?

 

ИМХО, любое промежуточное звено будет вносить свою задержку.

Вставьте слово "возможно".

 

Прогоните тот же тест с более удаленным сервером, результаты будут существенно лучше.

Нет, всё останется так же, ибо система вносит страшный джиттер.

 

Добавлю:

а) Я этот тест опубликовал, чтобы те кто хотят купить систему кеширования, провели его и не сделали ошибки при принятии решения о приобретении.

б) Не говорите правильный это тест или нет, пока не пройдете его на собственной системе.

в) Предполагаю что причиной может быть быстрое "остывание" данных в памяти, под нагрузкой. Хотя, по количеству памяти в сервере и тем более по её занятому объему - всё еще хуже. К примеру, у меня на НАС-ах стоят транспарент-Сквиды, для кеширования избранных направлений (хостинги статического контента и т.п.), так там памяти по 96 Гиг установлено + наборы SSD. Вот с них отдача показательная.

г) Кешмара должна показать отличные результаты, т.к. на сколько мне известно, движок там ***ный и прокаченный Сквид.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы специалист поддержки PeerApp'а или владелец системы?

Владелец.

г) Кешмара должна показать отличные результаты, т.к. на сколько мне известно, движок там ***ный и прокаченный Сквид.

for SEQ in `seq 1 100`; do echo $SEQ; time curl -s http://forum.nag.ru/forum/uploads/av-2437.gif >/dev/null; sleep 1; done

 

Напрямую: 470-350 мс.

Через кашмару: 150-12 мс. (первый запрос 264 мс.). В основном до 20 мс, иногда около 50, несколько раз проскочило 150.

 

Кашмара загружена на 70%.

Думаю, задержка около 10 мс - минимально возможная, это значение можно принять за "ноль". Это как раз задержка на логирование и основную логику. Ни и всякие посторонние задачи (например обслуживание веб-морды) вызывают изредка большие задержки.

Ну и некоторый разброс результата, ИМХО, - ничего страшного.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Да, проднялось нормально.

 

SKIPPIE

 

Мы попробовали, все получилось ... и отказались. Слишком диск нагружается, начинает проседать HTTP трафик. 8хSAS винтов не успевают и HTTP и P2P кеш обслуживать.

HTTP более приоритетное.

 

А я отключил, потому что эффективность низкая.

50-60 Мбит в пике.

 

Мы попробовали, все получилось ... и отказались. Слишком диск нагружается, начинает проседать HTTP трафик. 8хSAS винтов не успевают и HTTP и P2P кеш обслуживать.

 

А кластер не пробовали собирать?

 

Коллеги, кто-нибудь использовал в работе решение DiviNetworks ?

Имеем от них предложение, пока не принимаем никаких решений.

 

Возьмите на тест. Они в этом плане очень лояльные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Блин, ну отключите вы эту дурацкую фичу собирания всех ответов в один пост!!!!

Бесит неимоверно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Владелец.

Прекрасно. Теперь поделитесь какие это логи вы там смогли отключить? ;)

 

Напрямую: 470-350 мс.

Через кашмару: 150-12 мс. (первый запрос 264 мс.). В основном до 20 мс, иногда около 50, несколько раз проскочило 150.

 

Кашмара загружена на 70%.

Думаю, задержка около 10 мс - минимально возможная, это значение можно принять за "ноль". Это как раз задержка на логирование и основную логику. Ни и всякие посторонние задачи (например обслуживание веб-морды) вызывают изредка большие задержки.

Ну и некоторый разброс результата, ИМХО, - ничего страшного.

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

Оно конечно, когда у вас такой безумный джиттер до нага, то действительно 20мс ничего не решат. И я могу вам только искренне посочувствовать. Но тем не менее, за "ноль" надо брать минимальное значение по результатам тестов на стенде.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.