Backend rapid pt forumuri – mii de cereri/secunda pe hardware modest

Pentru a pune in practica niste idei de arhitectura si a iesi putin din cotidian, m-am gandit sa incep un proiect open-source mai exotic: un proiect web in C++. Mai exact, un backend de forum, pentru a avea un domeniu nu foarte complex, dar nici chiar un banal blog.

Tinte:

• Cat mai rapid, eliminand cod inutil (de exemplu: nu serializam/deserializam datele de 10x inainte de la transmite clientului)
  
• Cat mai eficient cu memoria (o masina cu 1 GB RAM sa poata gestiona sute de mii de mesaje, cu multi clienti simultani)

https://github.com/d...rum/tree/master

Edited by dani.user, 01 June 2020 - 22:05.

De laudat initiativa, sunt sigur ca toti participantii vor avea multe de invatat.

Quote

cred ca ai fi putut veni cu idei mult mai bune de proiecte open source

Quote

scriind implementari proprii de json, escaping, whatever, mi se pare cod inutil

Quote

la ce bun cand poti face fire la inca o masina in cloud? ce alegi, sa stai 3 ani sa scrii
un soft sau sa folosesti un framework sa il scrii in 2 luni - si tare cred ca vei avea performante
mai marei cu a doua varianta.

Arunca un ochi peste asta si zi-mi daca iti mai vine sa folosesti c++ pentru web dev

 puya4ever, on 21 septembrie 2016 - 15:32, said:

Alea mai bune nu le fac open-source.

 puya4ever, on 21 septembrie 2016 - 15:32, said:

Implementarea respectiva am scris-o mai demult cu alta ocazie cand gaseam doar biblioteci ce ma fortau sa creez diverse structuri inainte de serializari, lucru ce vreau sa-l evit.

 puya4ever, on 21 septembrie 2016 - 15:32, said:

Aici e lunga discutia. Imi place sa optimizez treburi, nu doar sa umplu buzunarele altora.

 puya4ever, on 21 septembrie 2016 - 15:32, said:

Poti sa-l numesti un fel de experiment pentru a arata ca, odata ce stii ce faci, diferenta e mult mai mica. Fiind un proiect tip hobby, nu ma forteaza nimeni sa fie gata ieri.

N-am zis ca nu voi folosi treburi gata facute, treaba cu json-ul e mai mult o exceptie. Performanta va veni din treburi mai subtile cu rol de a minima pe cat posibil ceea ce are procesorul de facut pentru a raspunde fiecarei cereri, iar C++ se preteaza la asa ceva, fata de framework-uri gen spring unde vezi callstack-uri de zeci de membrii sau unde multe treburi se "wire-up" la rulare, pe cand C++ are grija sa "paveze drumul" inca din momentul compilarii.

Edited by dani.user, 21 September 2016 - 18:52.

Incep sa se observe formele structurilor de date si a mecanismului de protectie thread-safety.

Pe un server *nix, cum ar prefera potentiali hosteri sa vada metrici in timp real? Ce platforme de genul sunt la moda?

Edited by dani.user, 10 October 2016 - 16:26.

Commit-ul cu numarul 100 (fata de branchul master) aduce referinte in cadrul userilor pentru identificarea rapida a topicurilor create.

Avand in vedere ca, in cazul unui forum, inserarile de noi date sunt mult mai frecvente decat editarile/stergerile si ca nu am nevoie de limbaje de interogare gen SQL, m-am gandit sa persist datele folosind Event Sourcing.

Avantaje:

• Viteza mare de scriere (append only, nu stau sa caut unde anume sa modific ceva)
  
• Istoric bogat

Dezavantaje:

• Raman mizeriile

Pareri?

Ce features sugereaza publicul? Ce v-ar fi placut sa vedeti in softuri similare dar lipsesc cu desavarsire?

 dani.user, on 26 decembrie 2016 - 18:25, said:

Sa poti sa modifici textul topic-ului, sau macar o parte din el. Ca sa prezinti anumite update-uri.
Sa poti sa conlucrezi pe un topic cu mai multe persoane, eventual pe baza unui vot.
Sa ai scoped reply ca la facebook.
Sa poti sa ascunzi mari bucati din conversatii si sa ramana ca un fel de rezumat, probabil cele mai importante raspunsuri, deoarece sunt foarte greu de citit si urmarit.
Creatorul sa aiba anumite drepturi pe topicul creat.
Un topic sa apara in mai multe categorii la alegere, de exemplu si in fun dar si la muzica daca tine de ambele.

Mersi de idei.

• Ultima e acum in lucru. Topicurile nu vor fi asociate direct unor categorii ci vor primi tag-uri. Categoriile vor grupa apoi taguri, iar topicul va aparea in orice categorie ce include macar unul din tagurile asociate.
  
• Pentru filtrare voi introduce probabil posibilitatea de a colapsa continut functie de diverse criterii. Posibil sa introduc un fel de scor votabil care sa indice cat de ontopic e fiecare mesaj
  
• Daca prin scoped reply intelegi sa poti forma arbori de conversatii in acelasi topic, nu ma atrage ideea.
  
• Drepturile de acces vreau sa fie flexibile, cu accent pe contributii utile individuale.

Traiasca TDD. Deja sunt mai multe linii de cod de test, decat de functionalitate efectiva

Edited by dani.user, 01 January 2017 - 20:28.

Cum se vor stoca fisierele atasate (blob)?

Edited by 4evryng, 01 January 2017 - 20:25.

Pentru atasamente ma gandeam la cloud, S3 sau Azure Blobs

Partea de atasamente as pastra-o ca un serviciu separat, comunicand cu cel principal doar pentru autorizarea fiecarui upload/download. Nefacand altceva decat sa ia dintr-o parte si sa trimita in alta, ar putea fi scrisa in orice, chiar folosind node.js.

Un API (REST) ar fi bine-venit. De exemplu daca vreau sa-mi fac propriul client (open-source ca sa fim pe aceeasi idee ) pentru mai multe platforme (PC/mobile/whatever) va exista posibilitatea sa consum un REST API astfel incat user-ul forumului sa-mi autorizeze (folosind OAuth 2.0) my third party client si sa afisez forumul, notificarile etc?

Edited by 4evryng, 02 January 2017 - 14:47.

Da, serverul va expune doar endpointuri REST. Tot ce tine de UI vreau sa deleg la client, ca doar avem nspre core-uri si in telefoane (vreun compromis va fi facut probabil doar pentru crawlere)

Autentificarea la fel va fi delegata via OAuth. Nu vreau sa reinventez roata si sa-mi bat capul cu "forgotten password" si alte asemenea.

Edited by dani.user, 02 January 2017 - 14:50.

Pe partea de autorizare apare o dilema: tot felul de optiuni configurabile, sau scripting via bucati de python?

Edited by dani.user, 29 January 2017 - 14:05.

Boost signals simplifica implementarea observers, reducand si codul duplicat necesar pentru mocking.

Edited by dani.user, 08 January 2017 - 19:42.

Cum numarul de linii de cod a depasit 10.000, imi permit sa ma cer parerea cu privire la cod.

Ar fi interesant cum il vad si cei ce scriu doar Java sau cei ce au/aveau multe prejudecati la adresa C++.

Am implementat categorii ("arii") combinate cu tag-uri. Astfel un topic poate face parte din mai multe categorii in acelasi timp, pentru a fi mai usor de gasit.

Cel mai important: atunci cand se creaza un nou topic, nu se specifica categoria din care va face parte, ci se speficica tag-uri cat mai sugestive, sistemul avand grija apoi sa afiseze topicul unde-i e locul.

Totalurile (cate topicuri/mesaje) din cadrul categoriilor sunt calculte in timp real, astfel incat prezinta mereu informatie actuala. A fost o provocare calcularea lor eficienta, dar cu grija la evitarea dublurilor.

Quote

Erau mai sus comentarii la adresa reinventarii rotii in ce priveste serializarea la json. Cum categoriile formeaza o structura arborescenta si cu referinte ciclice in ce priveste tag-uri, solutia custom mi-a permis sa specific foarte usor ce parti sa includ in serializare la un moment dat (ex. daca afisez copii ariei de programare, nu afisez pentru fiecare ca parintele lor e programare). Cu biblioteci obisnuite de serializare ar fi fost foarte aiurea de definit asta fara populez structuri secundare.

Edited by dani.user, 29 January 2017 - 13:59.