Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[RC5] Прокси 335 и большой слив 30.12.03 10:26
Автор: Kost <Пробки Москвы> Статус: Elderman
Отредактировано 30.12.03 10:26 Количество правок: 1
|
На днях обновил прокси. А вот сегодня кто-то слил хорошую пачку блоков на 26K. И все нормально прошло, выходной буфер отправлен весь.
2003-12-30 06:31:26,Status: rc5-72: Last uplink sent 107 and received 94
2003-12-30 06:37:53,Status: rc5-72: Last uplink sent 2276 and received 210
2003-12-30 06:41:14,Status: rc5-72: Last uplink sent 127 and received 127
за 6 минут отправлено 2300 блоков. Наверное действительно что-то поправили в скорости обмена.
http://rc5.pp.ru/proxy/
|
|
это гуд, но все равно не быстро.
30.12.03 18:10
Автор: BlackElf Статус: Незарегистрированный пользователь
|
> за 6 минут отправлено 2300 блоков. Наверное действительно
> что-то поправили в скорости обмена.
это гуд, но все равно не быстро.
сливать 1-1,5 метра в течении 3-4 часов напрягает.
|
| |
да ладно.... 5 мегов ушло за полчаса по модему. 01.01.04 16:05
Автор: mss <Сергей> Статус: Member
|
|
|
| |
[RC5] увеличить количество ниток? 31.12.03 04:11
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 31.12.03 05:18 Количество правок: 2
|
"[KeyServer]/maxservers: Determines the maximum number of simultaneous upstream server connections will be used to fetch or flush. It might be useful to increase this number if you frequently need to upload or download a large number of blocks at a single time, and it seems that individual server connections are slow or have high latency. The default value is 1 and the maximum number you can specify is 4."
(с) perproxy/manual.html
какой у тебя пинг с центрального прокси до апстрима? он точно оптимален?
предполагается, что для таких больших сетей как у тебя, connection с нтернетом круглосуточный, а скорость обмена твоего центрального прокси с апстримом превышает суммарную всей твоей сетью скорость просчета блоков (если не так.... вааааау - пиши днетовцам в саппорт :)
не позволяй скапливаться большим пробкам. любой исходящий буфер более 10-20К - это уже ненормальная задержка. на клиентах, подключенных к перпрокси через бесплатную локальную сеть, лучше отсылать вообще каждый блок - стараясь поддерживать все исходящие буфера всех клиентов вечнопустыми. (перегрузка прокси? - несколько прокси каскадом) на центральном прокси, разумеется, критичный размер исходящего буфера имеет смысл делать больше 1 блока :) - но скапливать мегабайт или полтора - совершенно никак не допустимо, имхо.
или, может быть, у тебя это получаается при оффлайновом обмене? ох, зря днетовские девелоперы не реализовали в прокси такую очень полезную фичу клиента, как -import. прокси по их мнению, я так понимаю, для оффлайна не предназначен, увы - а обмен через сетевые файлшаринги обладает рядом минусов и на твоей мощности полностью загнется за пару часов. а может быть, для оффлайнового приема нужны отдельные экземпляры проксей в отдельных каталогах, не отвечащие клиентам? рождается - сливает (хоть 5 часов). заканчивает. да или вообще пусть себе висят еще 2-3 демонами, почему нет. зачем следить за этим, зачем ждать? скрипт: 1) стопишь вспомогательного демона, 2) кладешь ему буфер, 3) запускаешь демона, 4) он себе сливает куда нужно. однажды отладив, про систему можно забыть - вышлется как сможется. достаточное условие для спокойствия - "скорость обмена твоего центрального прокси с апстримом превышает суммарную всей твоей сетью скорость просчета блоков".
ну и совершенно извращенное решение, если совсем никак - разделить сеть на небольшое количество участков и апстримить их независимо :) - возможно и на одной машине запуская несколько независимых прокси на разных портах. хотя мне и сложно представить себе ситуацию, когда эта кривота была бы хоть как-то оправдана.
смотри как я везде почти без изменений прописываю [networking]
|
|
|
подробно о проекте
Анализ криптографических сетевых...
