Полная переустановка не нужна.
Достаточно вернуть на место tcpip.sys и вписать в реестр, что он рабочий. Это все есть в моем скрипте одним постом выше.
Ага. Его уже два месяца плющит: local.com.ua/forum/topic/40620-ua-ix-troubles.
Не имею ничего против Extreme-ов (у самого стоит, нравится), но реакция вендора странная — нет чтобы тупо заменить на что-либо более производительное, так они наживую ковыряют.
У любого кеша есть свой оверхед, это надо понимать.
Если кешировать то, что можно и так получить из базы одним простым SELECT-ом, то разница в скорости скорее всего получится вообще отрицательной.
А вот для «тяжелых» рассчетов — это да, это оно.
Я кстати в одном проекте вообще запускаю наполнение кеша некоторых значений параллельно с основным потоком.
Не понимаю, чем предложенный вариант лучше вот этого.
А насчет
Надеяться что любой тег проживет дольше записи помеченной этим тегом мне кажется слегка легкомысленным.
можно сказать, что надеяться на любой кеш — вообще легкомысленно. Кеш — это непостоянное хранилище, которое может в любой момент оказаться пустым, и это нормально.
Проблема в том, что ISC DHCPd (а больше вариантов-то, собственно, нет) совсем не предназначен для работы с Option 82.
Во-первых, есть проблема с клиентами-«перетыкальщиками»:
1) Клиент подключился, получил lease.
2) Вынул кабель, подключил другое устройство (холодильник, допустим). DHCP-сервер в таком случае не выдаст ему IP-адрес, т.к. он уже выдан первому устройству (т.е. занят).
Решается патчем, но это больше хак, чем решение.
Во-вторых, и это самое главное, для Option 82 в конфиге dhcpd нужно вписывать каждого клиента. Получаются полотна. При этом, каждый раз при смене конфига нужно перезагружать демон.
Мой dhcp-сервер работает с базой, без всяких извратов. Как дополнительная плюшка — получаем удобство получения данных из внешних систем (например, в ERP у меня есть «лампочка» — получил клиент IP или нет).
Достаточно вернуть на место tcpip.sys и вписать в реестр, что он рабочий. Это все есть в моем скрипте одним постом выше.
Фикс:
depositfiles.com/files/6vjn6zri4
У меня логика такая: если у всех работает, а у кого-то конкретного — нет, значит, проблема у пользователя.
Не имею ничего против Extreme-ов (у самого стоит, нравится), но реакция вендора странная — нет чтобы тупо заменить на что-либо более производительное, так они наживую ковыряют.
Если кешировать то, что можно и так получить из базы одним простым SELECT-ом, то разница в скорости скорее всего получится вообще отрицательной.
А вот для «тяжелых» рассчетов — это да, это оно.
Я кстати в одном проекте вообще запускаю наполнение кеша некоторых значений параллельно с основным потоком.
А насчет можно сказать, что надеяться на любой кеш — вообще легкомысленно. Кеш — это непостоянное хранилище, которое может в любой момент оказаться пустым, и это нормально.
Там просто всё, вывалю сюда :).
Конфиг nginx-а прост:
Для просмотра использовал jwplayer:
publish-ил я ffmpeg-ом, конкретной строки запуска не сохранилось.
Смотреть любым flash плеером.
Если надо — есть рабочий сервер, могу слить конфиги.
Но на всякий случай подпишу.
Там есть мой вариант (работающий, только для relay + Option 82) и еще один от Ivan_83 (скорее скелет, без логики).
Во-первых, есть проблема с клиентами-«перетыкальщиками»:
1) Клиент подключился, получил lease.
2) Вынул кабель, подключил другое устройство (холодильник, допустим). DHCP-сервер в таком случае не выдаст ему IP-адрес, т.к. он уже выдан первому устройству (т.е. занят).
Решается патчем, но это больше хак, чем решение.
Во-вторых, и это самое главное, для Option 82 в конфиге dhcpd нужно вписывать каждого клиента. Получаются полотна. При этом, каждый раз при смене конфига нужно перезагружать демон.
Мой dhcp-сервер работает с базой, без всяких извратов. Как дополнительная плюшка — получаем удобство получения данных из внешних систем (например, в ERP у меня есть «лампочка» — получил клиент IP или нет).
Сравнивали коммутаторы Extreme Networks и Cisco?