Инкогнито

В самой кашмаре доступ саппорта не отключается только если система на тестировании. А когда нормальная лицензия - никто не мешает убрать доступ.

Купили в конце-концов кашмару. Пробовали свой сквид, но правила на всякие сайты мутить да отслеживать изменения... Кое что получалось, но эффект был хуже и проблем больше. В общем, раскошелились. )) Процент кеширования по трафику 40-50. Видео из кеша летает. Были некоторые проблемы, саппорт помог. Откликаются быстро. На p2p возлагали большие надежды, но как оказалось, под это дело надо шибко быстрые диски. Оставили с небольшим размером кеша (локальный ретрекер в кашмаре довольно эффективный). Если кто будет покупать в расчете на p2p, - надо диски по-шустрее. Можно поменьше размером и побольше штук в корзине. По деньгам, хоть оно и дорого, получаемся в плюсе. Клиенты довольны - ютуб и прочее идет куда веселее (до большинства серверов у нас большой пинг). Ну и нашу проблему (негде было взять трафик за адекватные деньги) решили успешно. Типа канал расширили в 1,5 раза на тех-же аплинках. )) Лично мне не хватает всяких "покрутить настройки", но работает. Может оно так и лучше? Типа "все из коробки". В общем, берите на тестирование если сомневаетесь.

)) У меня та же картина. Но странички стали открываться шустрее. Ютуб на SmartVT стал работать. Вообще видео по-шустрее стало. Но были жалобы от клинтов - то капча не обновляется, то заходят на форум под чужим логином. Пришлось добавлять "не кешировать". Сейчас вообще сделал регулярку - не кешировать если не статика. Сегодня время тестирования заканчивается. Склоняемся к тому, что расширить канал проще и дешевле. Да и геморою меньше. PS. Сквид "из коробки" позволяет задействовать почти любую СУБД, лишь бы драйвера были. Там даже посторонние исполняемые файлы могут участвовать.

Имеете ввиду железо? Речь вроде шла о софте. Как ни ускоряй, логика кеширующей системы сложнее, соответственно и медленнее будет на том-же железе. Конечно, если сравнивать кеш-систему на супер-пупер сервере, да массивом на SSD с веб-севером на древнем писюке... А деньги действительно просят неприлично большие. И что не понятно - основная логика давно уже есть в Open Source. Дорабатывают мелкие особенности, интерфейс управления и "бантики" в виде всяких диаграмм. Так с чего такие цены? Вот именно, - "с обеих сторон". А это не реально - ходить всем клиентам настраивать. И при потерях по ГОСТу (0,1%), да отклике ~200 мс не получится на многих OS.

Хм.. Смотря в каких условиях. Если я нахожусь "у черта на куличках", то каждый реальный запрос в Тырнет даст задержку минимум время пинга. У меня это обычно 150-250 мс. Итого, на странице с 20 элементами (картинки, стили, скрипты, прочее) получу задержку минимум 3-5 секунды. Это не считая задержек на самом сайте, т.е. только транспортный уровень. Второе - особенности TCP. При длинном плече сложно получить хорошую скорость даже при толстом канале (проблема длинных и толстых каналов). И в таком случае лучше если кеш-система сама будет взаимодействовать с клиентом на уровне TCP, а не перехватывать трафик. С другой стороны, если я нахожусь недалеко от дата-центров/магистралей, то и цена за трафик будет существенно меньше. И сложности с увеличением канала вряд ли возникнут. Соответственно и эффективность какой-либо кеширующей системы будет сильно под сомнением. Дешевле и проще просто увеличить канал. В идеале - да. Но в реальности вряд-ли возможно. Логика любой кеширующей системы гораздо сложнее, чем логика Веб-сервера, отдающего статику. В результате кеширующая система всегда будет отдавать данные из кеша с бОльшей задержкой.

Предположу, что сквид у вас настроен не оптимально. Или железо слабоватое, или загруженное сильно. Кашмара (тоже сквид, 8 SAS + 1 SSD) выдает результат лучше (9-35 мс - картинка с майл.ру). И в Вашем результате, который вы оценили на 5+, разброс в 3 раза. Следуя вашей логике - плохой результат. Локальный сайт у меня отдает статику гораздо лучше (7-8 мс). Но смысл не в этом. А в том, что кешировать локальный сайт смысла нет. Ну, если только с целью разгрузить его. Вот именно поэтому и оценивать любую кеширующую систему надо на достаточно удаленном сайте. А у меня, например, ВСЕ сайты удаленные. До майл.ру даже пинг 120 мс. Ютуб - еще дальше... А есть не просто удаленные сайты, а еще и "тормознутые"... И тут уж практически любая кеширующая система будет давать заметное уменьшение времени отклика. Если ее производительность позволяет, конечно. Тест ваш, безусловно, интересный. Но оценивать его результаты надо с умом. PS. И какая разница, локальный или уделенный? Если контент из кеша...

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

Владелец. 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 мс - минимально возможная, это значение можно принять за "ноль". Это как раз задержка на логирование и основную логику. Ни и всякие посторонние задачи (например обслуживание веб-морды) вызывают изредка большие задержки. Ну и некоторый разброс результата, ИМХО, - ничего страшного.

Упс... На цифры не посмотрел внимательно. Но думаю, учитывая "мс", вполне понятно. Отключите логирование и прочие посторонние задачи и наверное получите примерно то-же время загрузки через кеш. А может даже немного больше (т.е. хуже). ИМХО, любое промежуточное звено будет вносить свою задержку. Прогоните тот же тест с более удаленным сервером, результаты будут существенно лучше.

Имеете ввиду относительные min/max? Думаю, это неизбежно. Даже при пинге такое наблюдается. Например, пингую 8.8.8.8 - получаю 120-130 мс. Относительная девиация получается несколько процентов. Пингую соседний ПК, получаю 1-2 мс, относительная девиация 50-100%%. ИМХО, главное что средняя скорость на много больше.

Да, проднялось нормально. Надо настраивать локальный 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 более приоритетное.

CacheMARA, текущая неделя. googlevideo.com (лидер по объему): Общий объем трафика - 3,87 ТБ. Из кеша - 35,83%. Запросов всего: 8 475 252. Запросов из кеша: 55,92%. На данный момент по всему TCP-80 35-45 %% трафика - из кеша (ночью меньше, днем больше).

Тестируем CacheMara... Версия L-2000 (до 2G общего). За 3 дня набрался кэш 6,8 TB (доступный объем 32). Попаданий в кеш (объем) - 30-40 %%; если по к-ву запросов, то порядка 25%. Итоговая прибавка трафика до 350 М/с (завернули на кашмару только TCP-80). Машина мощная и дорогая - 2*Xeon-s2600 (в сумме 16 физических ядер), 100GB памяти, 8*SAS-HDD, 1*SSD (для системы). Настроек у кашмары маловато. Практически "черный ящик". Но работает красиво. Даже слишком красиво, подсознательно ожидаю "засады". Цена конечно приличная выходит - сам сервер + лицензия + сопровождение. Окупится ли прибавкой трафика - не понятно, но скорость веб возросла колоссально. А это клиентам нравится... Многие "тестируют Интернет" Ютубом.

По поводу статистики. В данный момент, 2 таких сервера (см. мой пост выше) обслуживают чуть меньше 500 клиентов. Постепенно переводим клиентов на DHCP. Поднято 2 таких сервера. Первый - основной, на нем веб-морда. Второй - регулярно (каждые 5 минут в рабочее время) обновляет базу с первого. За месяц на первом обработано 237450 и на втором 456559 запросов. Т.к. было замечено, что служба иногда падает, - каждые 10 минут рестарт сервиса. Если при рестарте служба не работала (упала), то сыпется сообщение на мыло (отрабатывает крон). За месяц было 2 таких сообщения. Для синхронизации: 1. На основном сервере поднят HTTP (все равно нужен для веб-морды), расшарена /lib/dhcp-perl/data/. 2. На основном сервере каждые 5 минут (в рабочее время, когда могут изменяться данные) запускается /lib/dhcp-perl#cat export 3. На втором сервере В файле /etc/hosts прописан адрес "1.dhcp" с IP первого сервера. Я решил, что так проще. /lib/dhcp-perl/get# cat get_sql Регулярно в рабочее время, каждые 5 минут, со сдвигом относительно первого сервера запускается /lib/dhcp-perl# cat import В результате, каждые 5 минут, если есть необходимость, на второй сервер заливаются новые данные. Если в какой-то момент времени (кратковременно) DHCP будет недоступен, - ничего страшного. На сервере настроено время аренды адреса 1 час. Через 30 минут клиент начинает пытаться продлить аренду. Чтобы за оставшиеся 30 минут клиент не смог "достучаться"... Это шибко маловероятно. Единственно, возможна проблема при первом получении адреса. Но 2 сервера (на свичах обычно можно указать 4), да клиент посылает несколько запросов... В общем, пока проблем не было. Были проблемы, но связаны с некорректными настройками интерфейса у клиента. В винде это лечится удалением сетевой карты в диспетчере устройств. Потом винда находит устройство и прописывает все параметры по-умолчанию. PS. 500 запросов в секунду... Клиент при получении адреса отправляет 3-8 запросов (зависит от OS). Будем считать 10. 50 клиентов в секунду получают адреса (500/10). Аренда - 1 час, обновление через 30 минут. Т.е. за 30 минут сервер выдаст 30*60*50=90000 адресов. Т.е. в нормальном режиме, при производительности 500 запросов/сек сервер способен обслужить 90к клиентов. Делим это на 2 (всякие форс-мажор) и получаем 45к. Так что насчет производительности, думаю, заморачиваться особо смысла нет. Но второй (а может 3 и 4) сервера имеет смысл иметь ради надежности. PPS. Для справки. Первый сервер - на той-же машине, что и биллинг (так удобнее для интеграции), - 2 камня по 4 физических ядра, памяти ... много. Второй сервер - на виртуалке, 2 виртуальных камня по 2 виртуальных ядра, 512 МБ памяти. Больше на этом сервере ничего нет (виртуальная машина специально для DHCP). В top процессов DHCP и не видно. На втором сервере, в данный момент, используется 311 МБ и 0-2 %% CPU.

В архиве: dhcp.sql - база без данных (структура). /lib/dhcp-perl/ - сам скрипт на перле + вспомогательные скрипты (импорт-экспорт, очистка логов). Запускать по крону или по необходимости. Очищаются логи старше 30 дней. /var/www/ - веб-морда. Там-же скрипт для выуживания маков (get_arp, в скрипте принято, что управляющая подсеть 10.156.0.0/16, используются для автоматического заполнения MAC адресов свичей в веб-формах). /etc/init.d/ - скрипт start/stop/restart в стандартном формате для Debian. В начале управляющие переменные с комментариями. По поводу структуры данных. Т.к. время от времени приходится свичи менять, пришлось ввести сущность "Расположение свича" - таблица locations. В результате, при смене свича достаточно изменить одну запись в базе - соответствие расположение-свич. В каждой таблице (кроме логов) поле "Примечание" уникальное. Если делать фильтрацию по примечанию, то поиск по части строки. Мы приняли у себя примечание - улица-дом-подъезд (свич или расположение) или улица-дом-квартира (клиент). В результате поиск "k81-" дает все свичи/расположения/клиенты дома k81. (k - проспект Комсомольский) В самом перл скрипте жестко задано время аренды адреса - 1 час, переменная $dhcp_lease_time. Можно задать свое значение. Также в скрипте жестко заданы 2 DNS сервера (192.168.1.249 и 192.168.1.250) и сервер времени 192.168.1.242 - поставьте свои. В веб-морде реализована "массовая смена IP". Надо выбрать расположение, указать какую подсеть меняем и на какую (формат х.х.х.). Возможен просто контроль (без фактического изменения). Поиск во всех формах регистро-независимый, формат MAC адреса свободный (разделители - точка, двоеточие, тире; регистр любой). При вводе MAC адрес преобразуется в нижний регистр, разделители двоеточие, сообщение. Клиент задается по расположению и порту. Дополнительно, можно указать MAC клиента (если не указан, то игнорируется). Если указан MAC клиента, то IP выдается только этому MAC. Логируются только запросы. Иногда полезно - узнать, а запрашивает-ли клиент. Возможна фильтрация по MAC/IP свича/клиента, по ID VLAN, по имени клиента (что клиент сообщает). При заполнении данных везде контролируется формат MAC и IP. Если неверный, то сообщение. Если удалось преобразовать к верному формату, что сообщение + в форме получившееся значение. Запись данных только если введенные значения в правильном формате. В свойствах клиента параметр "Отключен". Если пусто (или 0), то IP выдается. Если 1, то демон не отвечает. Из недостатков. Замечены случаи, когда демон аварийно прекращал работу. Причину выявить не удалось. Пока что просто периодически перезапускается. Данный демон работает уже более 3 месяцев. На данный момент обслуживает порядка 500 клиентов. Проблем (кроме вышеназванной) не выявлено. PS. Доступ к базе - localhost, dhcp, dhcp. PPS. Работает на Debian-5. dhcp-perl.zip