Ян. 302009
 

В момента правим тестове за това колко държи ЕСОЕД. Както знаете (от лекцията ми на пролетния семинар на БГПО миналата година), това е част от проекта за електронно правителство. В този проект аз участвам като database експерт – направих дизайна на БД и, по-важно, начините, по които Java приложението ЕСОЕД я достъпва.

Хавата е следната: влизат едни съобщения документи и се записват във входящата опашка. После се обработват на нещо като конвейер – проверяват се разни неща, подписват се, криптират се и т.н; готовите документи отиват в изходящата опашка, от където ги вземат Java процесите, които се занимават с изпращане и ги изпращат. Тук има една тъжна подробност: докато всички предишни обработки могат да стават колкото си искат паралелно, при изпращането трябва да изпращаме само по един документ към всяка система-получател, като този документ е изрично най-стария, т.е. документите се изпращат подредени. Това е един от най-конфликтните моменти, по който сме спорили мнооого дни, защото спъва скалируемостта. Но техническата му реализация е относително проста: има една функция в БД, която се извиква от всеки свободен изпращач. Тази функция намира документ, който:
– е в изходящата опашка, т.е. готов е за изпращане
– не е заключен от друг изпращач
– е най-стария неизпратен документ за тази дестинация, т.е. няма по-стар от него документ за същия получател, в никоя опашка
Щом намери такъв документ, функцията го заключва и връща неговото ID на Java-та, да си се занимава с изпращането.

Цялото това търсене на подходящ документ съм го реализирал с 1 (една!) заявка, която се пада най-тежката заявка в целия ЕСОЕД. И днес се изкефих колко оптимална е тя. В голяма степен заслугата за това е много добре измисления дизайн на БД и на работата с нея, за което претендирам да е моя заслуга.

Та тази заявка, оказа се, е изпълнена 631 147 пъти от последния рестарт на БД до сега, като за това е отнела общо 17 463 906 250 микросекунди процесорно време или общо около 17 960 692 000 микросекунди с включени всички други изчаквания (дискови операции и т.н.). Това е около 0,027670 CPU секунди на изпълнение или 0,028457 секунди по часовник. Пак казвам, това е най-тежката заявка в системата!

А най-красивото е, че при този дизайн, колкото и да се натовари системата (с много съобщения и стари данни), това време няма да скочи значително.

Обичам си професията! 🙂

 Posted by at 18:12

  5 Responses to “Натоварване”

  1. Да не си замесен и в системата на Търговския регистър, която е уникално глупава! Дава на заявленията „УНИКАЛЕН“ входящ номер от вида 20090130191745 … и какво ще стане като дойдат две заявления в една секунда? Идиоти…

  2. Бях се отчаял, че всички проекти за ДА се правят от гамени… добре, че има и хора като теб

  3. Здрасти – и аз мислех като този блогър – че всички държавни поръчки се печелят от няколко фирми, собственост на определени лица и по щастлива случайност те може да ги ‘препродадат’ на подизпълнители (като си дръпват лъвския пай за печалба) в случай че нямат служител, който да разбиреа в детайли какво точно ще правят.
    Примерно над 190хил за обикновено сайтче – тип склад на документи с търсене с някакво гръмко име…
    А, по същество – Направил си нещо като Distributed Lock Manager ли или просто DLM участва някъде зад кулисите така, че двама като викнат твоята функция на 2 различни сървера, тя да ги обслужи последователно, т.е. да не запише в някоя таблица че документа е едновременно заключен от 2мата или да запише че е заключен от първия и после че е заключен от втория, като даде и на 2мата да го изпращат ?
    na pseudocode mi izglejda taka:
    doc := null;
    Get_DLM_lock(); // wait here if locked
    doc=Get_a_doc_to_send();
    Release_DLM_lock();
    return doc;

  4. Не е точно така. Най-малкото не е distributed, a e централизиран, в една БД.
    Пък и алгоритъме е малко по-различен

Sorry, the comment form is closed at this time.