так небывает ) да и ненадо это мне например. Большие файлы по HTTP некачаю уже пару лет, торренты с таким обрывами справляются очень легко, чего еще хотеть )))
Понятно, что можно заплатить N баксов и купить железку для чего угодно…
Для тех, кто не верит — вот картинка
Вверху два объединяемях канала (2 и 1 mbps), внизу — график загрузки общего совместного канала (с разбивкой по классам HTB). Как видно загрузка достигает почти 3 mbps
для объединения каналов тут используется multipath routing — тоесть пакет к серверу A пойдет через один интерфейс, а к серверу B через другой. Через какой интерфейс пойдет пакет к серверу определяется случайно, с учетом весов, и маршрут кешируется, тоесть все последющие пакеты к серверу А идут через тот же интерфейс
решение о том, через какой канал пойдет пакет принимается на уровне маршрутизации. и без разницы, какой протокол — TCP или UDP — все пакеты к одному хосту пойдут через тот же канал
Да, надо понимать, что такая балансировка весьма приблизительна.
>>в два раза больше tcp-сессий
даже еще более грубо — 2/3 итернета будут открываться через один канал, 1/3 — через другой
но для торрентов (а это согласитесь основная нагрузка) такой балансировки хватает
Думаю нет, объеденить три канала свичем не получится, желательно иметь три сетевых карты, куда это все будет воткнуто. Хотя… может какими извращениями может удастся и с одной сетевухой.
Можно поставить аппаратный девайс, из «подешевле» DLink выпускает. А можно поставить Linux-маршрутизатор на самом убитом железе перед Windows машиной для объединения каналов. У меня все это крутится на Celeron 300 MHz, 256 MB RAM
Потому что ADSL у нас для домашних пользователей — до 4 mbps download, а upload всего 512 kbps, а старый добрый беспроводный канал — симметричный, честные 2 mbps. К тому же постоянный реальный IP, чем я пользуюсь, чтобы хостить у себя на сервере пару страничек.
Редактор внешнего вида очень понравился, а вот возможность собственных шаболонов слабоваты…
Очень плохо, что боты не хранят контекст диалога…
Еще было бы хорошо сделать более удобный редактор реплик, а то все приходится редактировать в одну строчку.
Пытался сделать консультанта для интернет-магазина, возникло куча вопросов…
Еще очень хотелось бы, чтоб в тексте реплики можно было б делать «гиперссылки» на ключевые слова.
Например бот говорит:
«Вы можете оплатить покупку с помощью VISA, Mastercard или PayPal.»
Пользователь кликает по подчеркнутому слову и получает рассказ по этому слову
Руки отрывать надо работодателям, которые дают такие тесты. А так же тесты вроде «каков результат выполнения такой программы в PHP версии 4 под Windows» и далее страница такого говнокода.
Даже если скрипт просто вернет готовую картинку, это означает что вызовется php, а это уже большие накладные расходы при высоких нагрузках.
На нашем проекте (более 400 запросов в секунду) мы применяем такой подход при отдаче новостей — если новость смотрят первый раз — 404 обработчик в nginx дергает php и тот отдает страницу и ложит ее в файл. В дальнейшем — nginx просто отдает статический файл (очень быстро) и не трогает php. Вот планируем и картинки перевести на такую генерацию (сейчас заранее делаем все размеры для каждой картинки).
вам уже ответили почему 404 лучше — в случае высоконагруженого проекта php для ресайза вызовется только один раз, а в предложеном вами варианте — будет вызываться снова и снова, создавая лишнюю загрузку на сервер.
Не надо изобретать велосипед — решение уже давно придумано )))
Надо сохранять в формате конкурента, добавляя (если формат позволяет) в него дополнительную информацию, которая позволяет реализовать все «фишки». Если у получателя такого файла ваша супер-программа — он увидит все ее преимущества, тк она считатет доп информацию из файла, если же у получателя старый софт — он увидит только базовые возможности, но все же сможет открыть файл.
Пример использования этого подхода — MP3 PRO формат — открывается и старыми плеерами, а устройства, которые поддеживают PRO использует доп информацию из него чтоб лучше воспроизводить низкие частоты. en.wikipedia.org/wiki/Mp3PRO
Для тех, кто не верит — вот картинка
Вверху два объединяемях канала (2 и 1 mbps), внизу — график загрузки общего совместного канала (с разбивкой по классам HTB). Как видно загрузка достигает почти 3 mbps
>>в два раза больше tcp-сессий
даже еще более грубо — 2/3 итернета будут открываться через один канал, 1/3 — через другой
но для торрентов (а это согласитесь основная нагрузка) такой балансировки хватает
Очень плохо, что боты не хранят контекст диалога…
Еще было бы хорошо сделать более удобный редактор реплик, а то все приходится редактировать в одну строчку.
Пытался сделать консультанта для интернет-магазина, возникло куча вопросов…
Еще очень хотелось бы, чтоб в тексте реплики можно было б делать «гиперссылки» на ключевые слова.
Например бот говорит:
«Вы можете оплатить покупку с помощью VISA, Mastercard или PayPal.»
Пользователь кликает по подчеркнутому слову и получает рассказ по этому слову
На нашем проекте (более 400 запросов в секунду) мы применяем такой подход при отдаче новостей — если новость смотрят первый раз — 404 обработчик в nginx дергает php и тот отдает страницу и ложит ее в файл. В дальнейшем — nginx просто отдает статический файл (очень быстро) и не трогает php. Вот планируем и картинки перевести на такую генерацию (сейчас заранее делаем все размеры для каждой картинки).
Надо сохранять в формате конкурента, добавляя (если формат позволяет) в него дополнительную информацию, которая позволяет реализовать все «фишки». Если у получателя такого файла ваша супер-программа — он увидит все ее преимущества, тк она считатет доп информацию из файла, если же у получателя старый софт — он увидит только базовые возможности, но все же сможет открыть файл.
Пример использования этого подхода — MP3 PRO формат — открывается и старыми плеерами, а устройства, которые поддеживают PRO использует доп информацию из него чтоб лучше воспроизводить низкие частоты. en.wikipedia.org/wiki/Mp3PRO