?

Log in

No account? Create an account

Previous Entry | Next Entry

"Прекрасно"

  • 11th Apr, 2015 at 1:59 AM
rabotka2
Я разработала систему, позволяющую передавать по корбе из одного процесса в другой структурированные иерархические данные любого размера. Например, бесконечного размера стримы XML или XDR, не говоря уже об "обычных" массивах байтов которые очень популярны в разных "быстрых" протоколах.

Там прикол в том, что обычно корба для таких целей не подходит, ибо она не streaming protocol как допустим TCP. Казалось бы.

Сегодня тестировала такой гипотетический сценарий: сервер посылает в десять клиентов одновременно десять разных потоков, каждый из которых являет собой "дерево" с 10 миллионами элементов. Каждый клиент все это пишет в файл, с символическим преобразованием из одного формата в другой. Например, на входе - XDR, на выходе XML. Память, потребляемая таким сервером - аж целых 20 мегабайт. Скорость - в среднем 2.7 секунды чтобы обработать все 10 * 10 миллионов элементов.

Тут на самом деле задача была не в том, чтобы оно быстро работало (это-то "просто"), а чтобы при этом был минимальных расход памяти. И при этом чтобы не было прямой зависимости между количеством подключенных клиентов и тредами (это "каждый может").

А то тут наши глобальные системы сценариев риска все время падают, когда у них кончаецца память. Я говорю, ну а какой размер хипа? Они говорят: да вот щяс поставили 5 гигабайт, но не хватает, наверное надо семь или лучше сразу десять. А я им: господа, вы звери, господа. С пятью гигабайтами оперативки можно все звезды в нашей галактике пересчитать и умножить на случайное какое-нибудь "редкое" число с плавающей какой точкой и поделить на минус це в квадрате, вы вообще что?

Кароче буду щяс постепенно своего монстра внедрять, прототип уже работает, причем с такой скоростью, что "ко мне уже глобальные архитекторы приходили". Их особенно поразило, что обработать 10 миллионов элементов занимает 2.7 секунды, 20 миллионов - тоже 2.7 секунды, 50 миллионов - опять 2.7 секунды, 100 миллионов - около 3.8...

Больше 100 миллионов я не пробовала, потому что эта адская машинка пишет несколько гигабайт в секунду на диск, "волнуюсь за комп". Но прикольно было стареть, как хип сидит в пределах 20 мегабайт и не увеличиваецца вообще.

Там принцип такой: абсолютно каждая отдельная операция (пусть хоть 2+2) осуществляецца в собственном буфере, в котором токо этого рода операции содержацца (с определенным ограничением на размер буфера и оптимальным количеством тредов, вынимающих из него объекты для преобразования), а результат каждой такой операции идет в следующий буфер, в котором повторяецца то же самое, и так до тех пор, пока нить преобразования каждого элемента не заканчиваецца. Другими словами, "многозадачность, доведенная до фанатизма". При нулевой рекламации всех участвующих в этом деле объектов (ну типа object pool там, каждый с тремя внутренними буферами - один для "изъятых" объектов, другой для "вернувшихся", а третий для перефасовки из "вернувшегося" буфера в "изъятый" чтобы не было блокировки при возвращении объектов).

Ну там еще есть ряд тонких деталей, но принцип простой: не позволять скопления объектов ни в одном из тредов больше чем позволяет буфер, а любая из операций, занимающая не-моментальное время должна выполняцца *одним из нескольких тредов*, с таким расчетом чтобы снизить глобальное замедление, которое обычно такие операции вызывают.

Чтобы это проиллюстрировать, представьте что вы едете по шоссе на большой скорости, и там много машин, но всего три полосы. В какой-то момент чел перед вами начинает как-то вяло рулить, вы переходите в другой ряд. Тот, кто за вами вынужден притормозить. Тот кто за ним, вынужден притормозить тоже, и так до тех пор пока не остановяцца *все*. Возникает пробка.

А при моем сценарии, условно говоря, если кто-то тормозит перед вами, вы быстренько въезжаете на запасное шоссе, очень короткое, которое специально для этой цели прямо к вам временно подводят, а потом его сразу перебрасывают на другой участок, и таких запасных шоссе там штук 500, "хватает на всех". И шоссе эти умеют мгновенно перемещацца на любое расстояние в любую проблемную точку, а когда движения мало, они сами автоматически закрываюцца, а потом снова открывюцца в нужном количестве.

Ну не прекрасно ли это?


Comments

( 3 comments — Leave a comment )
drupals wrote:
11th Apr, 2015 18:07 (UTC)
Прекрасно, конечно. Нужно эту систему наверное назвать как-то красиво. quick star, например
nasha_sasha wrote:
11th Apr, 2015 23:07 (UTC)
Мы пока временно ее назвали 'shelby' - по имени инженера спортивной легендарной машинки AC Cobra (на ней во второй серии кил-билла она едет убивать билла)
drupals wrote:
12th Apr, 2015 07:00 (UTC)
Красиво! Корба-кобра обыгрывается. К своему стыду, 2-ю часть Киллбилл не посмотрел
( 3 comments — Leave a comment )