В момента правим тестове за това колко държи ЕСОЕД. Както знаете (от лекцията ми на пролетния семинар на БГПО миналата година), това е част от проекта за електронно правителство. В този проект аз участвам като database експерт – направих дизайна на БД и, по-важно, начините, по които Java приложението ЕСОЕД я достъпва.
Хавата е следната: влизат едни съобщения документи и се записват във входящата опашка. После се обработват на нещо като конвейер – проверяват се разни неща, подписват се, криптират се и т.н; готовите документи отиват в изходящата опашка, от където ги вземат Java процесите, които се занимават с изпращане и ги изпращат. Тук има една тъжна подробност: докато всички предишни обработки могат да стават колкото си искат паралелно, при изпращането трябва да изпращаме само по един документ към всяка система-получател, като този документ е изрично най-стария, т.е. документите се изпращат подредени. Това е един от най-конфликтните моменти, по който сме спорили мнооого дни, защото спъва скалируемостта. Но техническата му реализация е относително проста: има една функция в БД, която се извиква от всеки свободен изпращач. Тази функция намира документ, който:
– е в изходящата опашка, т.е. готов е за изпращане
– не е заключен от друг изпращач
– е най-стария неизпратен документ за тази дестинация, т.е. няма по-стар от него документ за същия получател, в никоя опашка
Щом намери такъв документ, функцията го заключва и връща неговото ID на Java-та, да си се занимава с изпращането.
Цялото това търсене на подходящ документ съм го реализирал с 1 (една!) заявка, която се пада най-тежката заявка в целия ЕСОЕД. И днес се изкефих колко оптимална е тя. В голяма степен заслугата за това е много добре измисления дизайн на БД и на работата с нея, за което претендирам да е моя заслуга.
Та тази заявка, оказа се, е изпълнена 631 147 пъти от последния рестарт на БД до сега, като за това е отнела общо 17 463 906 250 микросекунди процесорно време или общо около 17 960 692 000 микросекунди с включени всички други изчаквания (дискови операции и т.н.). Това е около 0,027670 CPU секунди на изпълнение или 0,028457 секунди по часовник. Пак казвам, това е най-тежката заявка в системата!
А най-красивото е, че при този дизайн, колкото и да се натовари системата (с много съобщения и стари данни), това време няма да скочи значително.
Обичам си професията! 🙂