Spring și procesarea imaginilor. Interviu cu Mihăiță Țintă și Bogdan Arvinte

Luminița Voicu
Desktop Publisher @ Today Software Magazine

Prezentarea voastră de la The Developers 2024 a fost foarte apreciată de public : procesarea de imagine server side și integrarea cu un llm.

Care a fost arhitectura aplicației?

Mihăiță Țintă: Intenția noastră a fost să discutăm pe baza unei aplicații near-realtime în care două sisteme funcționează concomitent pentru a afișa informații utile clientului final. Arhitectura este una simplificată în care un client (browser) stabilește o conexiune bidirecțională cu un server web. Acesta, la rândul său, consumă serviciile unui alt sistem mai greoi de care însă depinde funcționalitatea de bază a aplicației: sistemul apelat rulează un model LLM pentru a putea decoda imagini din streamul video primit de la user în emoții afișate sub formă de emoji.

  Am văzut că ați ales 12 frame-uri pe secundă. De ce nu ați mers pe 24? Ce implicații ar fi avut asta în partea de procesare?

Bogdan Arvinte: Din punct de vedere vizual, versiunea cu 12FPS era aproape de cea cu 24FPS ca percepție a mișcării utilizatorilor (imagini de tip selfie). Micșorând această cifră, numărul de mesaje din rețea a devenit mai mic.

În aplicație, userii se pot vedea simultan, iar fiecăruia îi este asociată în mod constant o emoție. Avem așadar două funcționalități - streamul video de imagini de tip broadcast - toată lumea vede pe toată lumea - și procesarea imaginilor, care presupune că la fiecare secundă este afișat un anumit emoji. Cum această a doua operație consumă foarte mult CPU pe partea de procesare, decizia noastră a fost să limităm apelurile externe pentru un mic procent din imaginile primite de la user. În practică, nu ar fi ajutat să avem un emoji pentru fiecare frame, deoarece utilizatorii ar fi putut vedea aproape doar emojis, în loc de imaginile celorlalți.

  Cum ați fixat prima eroare simulată legată de transmiterea datelor prin threaduri concurente și cum ați optimizat soluția?

Mihăiță Țintă: Scrierea mesajelor prin websocket folosea un obiect nesincronizat în Java, iar unele threaduri ajungeau să eșueze în a scrie frame-urile trimise către alți utilizatori. Din acest motiv, sesiunea de websocket este închisă, deconectând practic fiecare utilizator afectat. Prima variantă a fost să folosim o altă implementare thread-safe în care un singur thread va putea scrie mesaje pe sesiune. În practică, în momentul în care am folosit un număr foarte mare de threaduri de sistem, această sincronizare a arătat o penalizare a performanței. Varianta cu threaduri virtuale a fost mai bună, deoarece un număr mic de threaduri de platformă au fost folosite pentru a realiza scrierea mesajelor.                   

Care este volumul de imagini procesate pe secundă din simulare?

Bogdan Arvinte: În simulare am reușit să plimbăm 270.000 de mesaje pe secundă între 150 de utilizatori pentru a avea percepția unui video care nu se mișcă sacadat. Pentru o mică parte din acele imagini am adăugat analiza emoțiilor, astfel încât la fiecare moment să existe câte un emoji pentru aproape toți utilizatorii.

Menționați-ne care este una dintre cele mai importante optimizări de cod realizate în timpul demo-ului.

Mihăiță Țintă: Dincolo de orice optimizare, am avut o înțelegere mai bună asupra a ceea ce se întâmplă în sistem abia după ce am activat metricile și am construit câteva grafice. Activarea de virtual threads este o schimbare ușoară (toggle on/off în spring), dar și ea, ca orice altă optimizare, trebuie însoțită de dovezi concrete de îmbunătățire a performanței, nu ne putem baza pe presupuneri.

Față de o prezentare obișnuită un demo poate avea și probleme. Cum a mers demo-ul vostru?

Bogdan Arvinte: Prezentarea noastră a avut loc la mijlocul zilei și ne-am putut bucura de conținutul prezentat de speakerii de dinaintea noastră. Pentru a ne asigura că totul va decurge cum trebuie, am verificat din timp tot setupul local, astfel încât să minimizăm riscul unor incidente tehnice. Întregul proiect poate fi folosit ca studiu de caz pentru comunicare realtime, profiling de performanță sau integrare cu LLM, iar principala provocare a fost timpul limitat în care să ne încadrăm cu un astfel de subiect. Faptul că am putut testa aplicația cu ajutorul colegilor din sală ne-a oferit o satisfacție suplimentară și a contribuit la succesul demo-ului.

Ce v-a plăcut cel mai mult la conferința de anul acesta ?

Mihăiță Țintă: Orașul Cluj-Napoca ne este drag și ne bucurăm de fiecare dată când putem reveni aici. Participanții la conferință au fost activi de-a lungul prezentărilor; e un aspect pe care îl apreciem fiindcă ne ajută să înțelegem ce tip de informație este relevantă pentru ei și unde putem îmbunătăți prezentările sau sesiunile de demo.
Evenimentul a avut parte de discuții interesante și bine pregătite, iar speakerii invitați s-au ridicat la nivelul așteptărilor noastre, dar și al publicului, din ceea ce am putut observa în sală.