[Helios]

Что-то я полазил посмотрел на ThunderСache - так и не понял - может ли он 2 гигабита http прожевать с кешем допустим терабайт 20 или это для детей хотспота-кафе софт. Очень рад бы ошибиться, ибо софт ценой порадовал, но судя по тому что там микротики везде в примерах - его потолок 100-400 Мбит? И с лицензированием не догнал - если допустим иметь 3600 http/s в секунду - там похоже даже близко такой лицензии нет. Схема лицензирования по количеству одновременно открытых сокетов несколько напрягла. А если несколько абонентов-доктор-зло откроют их по несколько десятков тыс?

p/s пока пошел присматриваться к cachemara... вразумите кто-нить про thundercache пожалуйста.

[Инкогнито]

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

А я где-то говорил что отключил? И речь шла не о CacheMARA конкретно, а вообще о кеширующих системах. В кашмаре большинство логов не отключаемые. Во всяком случае под триальной лицензией. Да и вообще, там напильником разогнаться негде.

 

сделайте тот же тест с локальным сайтом, и покажите результаты

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

[ThreeDHead]

А я где-то говорил что отключил?

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

 

Дорогой, а зачем мне кешировать локальный сайт? И коню понятно, что там задержка будет даже больше чем самого сайта (сквиду надо сделать гораздо больше телодвижений чтобы отдать что-то из кеша чем нгинсу чтобы отдать статику). А учитывая, что напильником заточить кашмару (как у меня заточен нгинс) никак - тем более.

Вот тест через сквид, не с локального сайта, а с mail.ru картинку тянули:

(чуть ошибся, уже поправил результаты)

Напрямую    - min: 163, avr: 231, max: 364
Сист. кеш.  - min: 161, avr: 240, max: 378
Через Сквид - min: 63,  avr: 107, max: 199

А объяснение простое - Сквид умеет работать с памятью на 5+.

 

И относительный разброс результатов будет сумасшедший. Ну и что? Как мне это помешает кешировать ютуб?

Полностью согласен, что для Ютуба это совсем не критично. Только вот, средств, определить Ютуб там или не Ютуб - нету. Поэтому туда заворачивается весь (почти) http-трафик. Про покраску трафика и прочие извраты с вычленением сетей Ютуба, не говорю.

 

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

Изменено 10 января, 2014 пользователем ThreeDHead

[DimaM]

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

 

А если кеширующая система - это nginx? А вся "магия" на DPI

Тест с локальным сайтом не показывает никакой разницы - есть кеширующая система или нет

Просто КАШМАР какой-то :)

[ThreeDHead]

А если кеширующая система - это nginx?

Я описал способ проверки любой системы кеширования. И не знаю как в этом случае ведет себя nginx. Надеюсь что хорошо, но не думаю что лучше сквида. Хотя могу и ошибаться, т.к. энжином не кешировал никогда.

 

Тест с локальным сайтом не показывает никакой разницы - есть кеширующая система или нет

С какой системой кеширования?

[Инкогнито]

Вот тест через сквид, не с локального сайта, а с mail.ru картинку тянули:

Напрямую    - min: 163, avr: 231, max: 364

Сист. кеш.  - min: 161, avr: 240, max: 378

Через Сквид - min: 63,  avr: 107, max: 199

А объяснение простое - Сквид умеет работать с памятью на 5+.

Предположу, что сквид у вас настроен не оптимально. Или железо слабоватое, или загруженное сильно.

Кашмара (тоже сквид, 8 SAS + 1 SSD) выдает результат лучше (9-35 мс - картинка с майл.ру).

И в Вашем результате, который вы оценили на 5+, разброс в 3 раза. Следуя вашей логике - плохой результат. Локальный сайт у меня отдает статику гораздо лучше (7-8 мс).

Но смысл не в этом. А в том, что кешировать локальный сайт смысла нет. Ну, если только с целью разгрузить его.

Вот именно поэтому и оценивать любую кеширующую систему надо на достаточно удаленном сайте.

А у меня, например, ВСЕ сайты удаленные. До майл.ру даже пинг 120 мс. Ютуб - еще дальше... А есть не просто удаленные сайты, а еще и "тормознутые"...

И тут уж практически любая кеширующая система будет давать заметное уменьшение времени отклика. Если ее производительность позволяет, конечно.

 

Тест ваш, безусловно, интересный. Но оценивать его результаты надо с умом.

PS. И какая разница, локальный или уделенный? Если контент из кеша...

Изменено 10 января, 2014 пользователем Инкогнито

[ThreeDHead]

Инкогнито

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

Я тут подумал, что касается системы кеширования от PeerApp, то её некорректно сравнивать со Сквидо-подобными системами кеширования. У неё алгоритм работы иной.

Если Сквид сам принимает подключение, то UltraBand пропускает SYN от клиента к серверу, потом пропускает обратно SYN-ACK, и уже потом, получив TCP-HTTP-GET, система принимает решение что с ним делать, отдавать с кеша или пропустить запрос на сервер. Так вот в 100% случаях хендшейк будет проходить реально (если канал медленный, то медленно), не "кешируясь". Но это не минус системы, а скорее плюс.

 

И какая разница, локальный или уделенный? Если контент из кеша...

Системы кеширования, помимо задач экономии полосы, подаются так-же "под соусом" акселератора трафика. Так вот тест через локальный сайт, показывает насколько эта акселерация эффективна. В идеале акселерация, должна быть, как минимум не хуже, чем отдает контент локальный сайт. Это то к чему необходимо стремиться.

[Инкогнито]

Я тут подумал, что касается системы кеширования от PeerApp, то её некорректно сравнивать со Сквидо-подобными системами кеширования. У неё алгоритм работы иной.

Если Сквид сам принимает подключение, то UltraBand пропускает SYN от клиента к серверу, потом пропускает обратно SYN-ACK, и уже потом, получив TCP-HTTP-GET, система принимает решение что с ним делать, отдавать с кеша или пропустить запрос на сервер. Так вот в 100% случаях хендшейк будет проходить реально (если канал медленный, то медленно), не "кешируясь". Но это не минус системы, а скорее плюс.

Хм.. Смотря в каких условиях.

Если я нахожусь "у черта на куличках", то каждый реальный запрос в Тырнет даст задержку минимум время пинга. У меня это обычно 150-250 мс. Итого, на странице с 20 элементами (картинки, стили, скрипты, прочее) получу задержку минимум 3-5 секунды. Это не считая задержек на самом сайте, т.е. только транспортный уровень.

Второе - особенности TCP. При длинном плече сложно получить хорошую скорость даже при толстом канале (проблема длинных и толстых каналов). И в таком случае лучше если кеш-система сама будет взаимодействовать с клиентом на уровне TCP, а не перехватывать трафик.

 

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

 

В идеале акселерация, должна быть, как минимум не хуже, чем отдает контент локальный сайт.

В идеале - да. Но в реальности вряд-ли возможно. Логика любой кеширующей системы гораздо сложнее, чем логика Веб-сервера, отдающего статику. В результате кеширующая система всегда будет отдавать данные из кеша с бОльшей задержкой.

Изменено 12 января, 2014 пользователем Инкогнито

[ThreeDHead]

Логика любой кеширующей системы гораздо сложнее, чем логика Веб-сервера, отдающего статику. В результате кеширующая система всегда будет отдавать данные из кеша с бОльшей задержкой.

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

[Ivan_83]

Второе - особенности TCP. При длинном плече сложно получить хорошую скорость даже при толстом канале (проблема длинных и толстых каналов).

Скорость достаточную для HD TV (те ~10 мегабит) получить не трудно, но требуются небольшие настройки с обеих сторон.

[Инкогнито]

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

Имеете ввиду железо? Речь вроде шла о софте.

Как ни ускоряй, логика кеширующей системы сложнее, соответственно и медленнее будет на том-же железе.

Конечно, если сравнивать кеш-систему на супер-пупер сервере, да массивом на SSD с веб-севером на древнем писюке...

 

А деньги действительно просят неприлично большие. И что не понятно - основная логика давно уже есть в Open Source. Дорабатывают мелкие особенности, интерфейс управления и "бантики" в виде всяких диаграмм. Так с чего такие цены?

 

Скорость достаточную для HD TV (те ~10 мегабит) получить не трудно, но требуются небольшие настройки с обеих сторон.

Вот именно, - "с обеих сторон". А это не реально - ходить всем клиентам настраивать. И при потерях по ГОСТу (0,1%), да отклике ~200 мс не получится на многих OS.

[Helios]

Давайте обсуждать уже конкретику ) Со своей стороны могу поделиться скринами CacheMara. В общем и целом после теста от приобретения остановила цена продукта и стоимость поддержки. Скорость загрузки страничек - не выросла (хуже тоже не стала), чуть лучше стал работать контакт и одноклассники. Если брать - только для экономии полосы. Стабильность идеальная - за все время тестов ни одной жалобы от абонентов.

И еще есть у меня такое мнение, что никакой доморощенный squid не потянет базу из 70-80 миллионов скешированных объектов.

[telematic]

Давайте обсуждать уже конкретику )

 

А на каком железе всё это у вас крутилось?

[Инкогнито]

)) У меня та же картина. Но странички стали открываться шустрее. Ютуб на SmartVT стал работать. Вообще видео по-шустрее стало.

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

 

Сегодня время тестирования заканчивается. Склоняемся к тому, что расширить канал проще и дешевле. Да и геморою меньше.

 

PS.

И еще есть у меня такое мнение, что никакой доморощенный squid не потянет базу из 70-80 миллионов скешированных объектов.

Сквид "из коробки" позволяет задействовать почти любую СУБД, лишь бы драйвера были. Там даже посторонние исполняемые файлы могут участвовать.

Изменено 13 января, 2014 пользователем Инкогнито

[telematic]

Склоняемся к тому, что расширить канал проще и дешевле.

 

Иногда расширение не помогает.

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

С кэшем вы вы хоть часто проблем вывезете.

[ThreeDHead]

Был неоднократно замечен всплеск отдачи трафика из кеша, во время аварийных ситуаций у аплинка. В целом, аварии (занижение пропускной полосы) стали заметно легче протекать с системой кеширования. С другой стороны, сейчас эти ситуации проще контролировать при помощи DPI, при аварии накинул удавку на P2P и жди устранения спокойно.

 

Helios Какая классная статистика по сайтам. У PeerApp'а этого нет. Есть маленький топ самых больших файлов в кеше, но и он не особо показателен.

[DimaM]

DimaM (10 января 2014 - 14:11) писал:

Тест с локальным сайтом не показывает никакой разницы - есть кеширующая система или нет

С какой системой кеширования?

 

СКАТ DPI + NGINX, но это (пока) не совсем система кеширования, скорее замена GGC для тех, кому он не положен

или, скорее, для тех кому положен, но google выдал "детскую" версию и она тормозит.

[ArhAngel_John]

for SEQ in `seq 1 10`; do echo $SEQ; time curl -s http://upload.wikimedia.org/wikipedia/commons/9/9a/Gull_portrait_ca_usa.jpg >/dev/null; sleep 1; done

 

Без CacheMARA: min: 2.816s, max:10.025s

С использование CacheMara: min: 0.071s, max: 9.286s (первый раз)

1

real    0m9.286s
user    0m0.000s
sys     0m0.016s
2

real    0m0.074s
user    0m0.004s
sys     0m0.008s
3

real    0m0.073s
user    0m0.000s
sys     0m0.012s
4

real    0m0.093s
user    0m0.012s
sys     0m0.008s
5

real    0m0.073s
user    0m0.004s
sys     0m0.008s
6

real    0m0.074s
user    0m0.008s
sys     0m0.004s
7

real    0m0.071s
user    0m0.004s
sys     0m0.004s
8

real    0m0.073s
user    0m0.004s
sys     0m0.008s
9

real    0m0.074s
user    0m0.008s
sys     0m0.004s
10

real    0m0.075s
user    0m0.008s
sys     0m0.004s

 

Взял на тест. Пока только первый день

Изменено 19 февраля, 2014 пользователем ArhAngel_John

[ThreeDHead]

Взял на тест. Пока только первый день

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

[DimaM]

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

Есть какой-нибудь тест поинтереснее?

 

Без кэша:

real 0m0.008s

user 0m0.001s

sys 0m0.001s

 

real 0m0.006s

user 0m0.001s

sys 0m0.003s

 

С кэшем:

real 0m0.008s

user 0m0.002s

sys 0m0.001s

 

real 0m0.007s

user 0m0.001s

sys 0m0.000s

[ThreeDHead]

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

Боже мой, комбайн научился картинки кэшировать?

 

Есть какой-нибудь тест поинтереснее?

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

[DimaM]

Боже мой, комбайн научился картинки кэшировать?

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

 

:)

Скоро. Поставили у клиента на канал 2x10G, ждем когда кэшик наполнится.

[ThreeDHead]

Скоро. Поставили у клиента на канал 2x10G, ждем когда кэшик наполнится.

А пока кэшик не наполнился, в оффлайне? ;)

[DimaM]

А пока кэшик не наполнился, в оффлайне?

 

Да

[ThreeDHead]

А пока кэшик не наполнился, в оффлайне?

Да

Прикольно придумали :) А заказчику что сказали?