04-13-2015, 05:08 AM
Статусапдейтом грешит и сама птска. От этого никуда не уйти, да.
Один день из жизни сервера или "ОДМИН ЛОХАИТ!!"
|
04-13-2015, 07:33 AM
Pointer*Rage Написал:Что и когда я у тебя спрашивал? Все, что я спрашивал - ты не давал внятного ответа, отвечал мне в основном всегда айзен (это если говорить про то время, когда ты еще не самовыпилился из моих контактов). Да и я на самом деле сомневаюсь, что ты бы смог на них ответить, т.к. они были довольно таки специфичны (а-ля отлов создания обьектов через JDI) Так, что о чем может идти речь?
04-13-2015, 12:33 PM
не нужно ничего задерживать, нужно реализовывать так, чтобы СУ приходил тогда, когда надо. к тому же вообще почему именно к нему прицепились, пакет мелкий, меняет он "мало" данных. есть куда более толстые пакеты, которые также шлются на абы отослать. я не знаю какую хронику использует поинтер, но в тех, где появились exuserinfo, expetinfo, exnpcinfo и другие ништяки при должном их использовании можно сделать няшку крепче птски.
не могу представить ситуации, в которой была бы оправдана такая нагрузка. вариант из 200 гремлинов вокруг на которых кинули dot не предлагать:redlol:
04-13-2015, 01:12 PM
Zubastic Написал:Статусапдейтом грешит и сама птска. От этого никуда не уйти, да.И не только ими.
04-13-2015, 02:12 PM
Pointer*Rage Написал:Хорошая вещь, как и конфигурация отключения отображения трейдеров Очень не плохо бустит работу клиента (если конечно в сервере все держится на кноулистах и многопоточность почти не используется). В китайском оффе есть еще опция отключения Pawn объектов, залетаешь в город и ловишь дикие лаги, включаешь, и не видно никого (кроме чата). Город пуст, лагов нету, можешь торговать, принимать трейд и тд. В теории такую штуку можно запилить, и не только ее)
:gun1::es:
04-13-2015, 04:26 PM
Конечно профит с 5(или сколько там паков) на осаде, и при этом дикие лаги, слишком здраво выглядит. Но всеже; может место имеет быть факту, что не стоит на 1ну машину и сервер собирать оверадахера задротов? Откройте 2й, такой-же. Спадет пипл со 2го или первого - объединяем. Зачем вам тру проекты с 1000005000000 онлайна на 1н сервер? Люте же, глупо и люто.
Только не говорите, что это сложно "администрировать", читать сраные логи(пример абусса, с отдельным "типа" лог сервером). Ну это ИМХА Все, кончил, слился. Пакедава
04-13-2015, 06:35 PM
Так, господа. Опишите пожалуйста, если не влом, при каких условиях пакеты из группы "флуд" должны приходить. Заранее благодарен.
Можно и в ПМ, если это ещё пока жуткая тайна.
Родился, живу и когда-нибудь умру.
04-13-2015, 07:37 PM
Ну если у Вас в очереди, на запись 20 пакетов, с перекрывающимися данными, зачем отсылать все 20, если можно отослать один. Смысл задержки в накоплении изменений. Отсылать можно с допустимой задержкой, для человека это не заметно. Как много раз Вы реагируете на смену кадра, наблюдаете сигнал синхронизации? В этом нет ничего странного, это известная практика, алгоритм Нейгла тот же, он сделан для других целей, но тот же принцип. Придерживая мы избавляемся от ненужных данных для сети и нагрузки как на стороне пользователя, так и на сервере. Просто придерживать до приделов допустимой дельты, её можно легко рассчитать, по активности входящего и исходящего трафика. Посылая эти 20 пакетов, поток отрисовки пройдет по ним холостым ходом, отобразиться только последние обработанные изменение. А может там вообще при приходе этого пакеты вызывается перерисовка сцены, отсюдова может быть накладные расходы, на стороне клиента. send data size - размер данных при отправке.Потом на каждый параметр в отдельности можно рассчитать дельту и придерживать отдельные группы. Опять же надо считать, мат. часть. У меня просто нету бесконечного прироста скорости и квантового компьютера. Насколько мне известно при отключенном алгоритме Нейгла, Вы отсылаете данные без задержки, по сути сами формируете кадры. Сам TCP гарантирует доставку каждого пакета MTU. Проверка каждого пакета, на доставку, это накладные расходы, если превысить MTU на 1 байт это уже два пакета, насколько мне известно. Вот Вам пример: где: PHP код:
time check - время проверки на доставку send data size / MTU - количество пакетов (целочисленное деление без остатка) delay check - задержки на проверку, доставки. + еще общая потеря данных при отправке возникнуть может, повторная отправка. Размер данных можно подставить любой даже умножить размер пакета в байтах на количество, а если вычесть один, из количества, получите избыточность. Для однотипных пакетов PHP код:
packet count - количество пакетов packet size * (packet count - 1) избыточность информации, она превышает 90% процентов, это тихий ужас. send data size <= MTU в пределах допустимой нагрузки канала send data size > MTU увеличивает нагрузку на канал можно PHP код:
Просто посмотрев на результат после подстановки можно понять стоит это делать или нет, но в данном случае и так понятно, что реализация сервера, повторюсь, топорная, на оптимизацию или какие-то особые алгоритмы не "заточена". Все пользуются alpha сервером. Это решение задачи в конкретных условиях.
04-13-2015, 11:24 PM
Gattsu, возможно как-то не понял ваше сообщение, хоть и перечитал несколько раз. вы изобретаете нечто тяжелое, опираясь на шаткие условия.
как я уже упоминал выше - проблема не в том, чтобы отправить N пакетов, или сгруппировать их - а в том, что не нужно создавать N пакетов, когда можно обойтись одним
04-14-2015, 12:19 AM
KID, я тоже об этом. Ну не знаю, каждому разработчику свое, на то он и разработчик. Так привык делать, основательно "копать". Когда просто не интересно
|
« Предыдущая | Следующая »
|