Menadžment velikog broja upita

[milicagnjatovic]

Ovde će biti izložena razmatrana zapažanja iz #14 i #15. Biće izložena rešenja problema opterećenosti sistema.

[milicagnjatovic]

Ograničenje broja zahteva koje grader obrađuje u jednom trenutku

Iz dela #15.

Http Grizzly server može da ograniči broj upita koji se obrađuju u jednom trenutku na sledeći način:

  server.getListener("grizzly").getTransport()
                        .getWorkerThreadPoolConfig()
                        .setCorePoolSize(10)
                        .setMaxPoolSize(10);

Na osnovu testiranja je zaključeno da 10 paralelnih izvršavanja upita neće previše usporiti sistem. Usporavanje sistema pravi problem jer će izvršavanje upita preći vremensko ograničenje. Uklanjanje i uvećanje vremenskog ograničenja nema preterano smisla jer neefikasni upiti mogu da okupiraju sistem bez potrebe. Pre pokretanja gradera na serveru je potrebno izvršiti testiranje koliko zahteva može da se paralelizuje.

Smatram da je potrebno postaviti ograničenje na graderu koliko zahteva može da se obradi, a ne oslanjati se da server neće poslati previše zahteva.

Dodatno razmatranje bi bilo da li praviti red upita za izvršavanje, a ne oslanjati se na mogućnos bibiloteke. Generalno, bibiloteke imaju efikasnije implementiran sistem za oavakav menadžment, pa bi "ručna" implementacija dodatno usporiti. Ako razmatramo ove mogućnosti kada je pitanju konkretna implementacija:

• Grizzly server održava 10 paralelnih niti

  • Po dokumentaciji, podrazumevani broj niti je jednak broju procesora.
  • Grader prima zahtev
  • Pokreće skriptu za izvršavanje upita
  • Skripta se izvršava ograničeno vreme, 15 sekundi je trenutni limit za ozvršavanje upita, plus dodatno malo vreme za ozvršavanje diff-a, konekcije i nekoliko pratećih komandi
  • Na osnovu odgovora skripte se vraća odgovor na zahtev, koristi se jednostavno return
  • Ovde je važno da će odgovor dobiti korisnik koji ga je tražio pa nije potrebno slati dodatnu identifikaciju (koji zadatak i koji korisnik).
  • Potencijalni problem je što će server koji je poslao zahtev čekati dok se ne vrati odgovor. Na serverskoj strani bi bilo dobro implementirati sistem da nit koja čeka ne blokira pravljenje novih niti.
  • Ukoliko stigne više zahteva server pravi red zahteva koji će biti obrađeni, u konkretnoj implementaciji zahteva nema razlike.
  • Potrebno je staviti ograničenje koliko zahtev može da provede u čekanju, bolje korisniku vratiti da je server previše zauzet nakon pola minuta, nego čekati 3 minuta.

• Ručna obrada velikog broja zahteva

  • Grader prima zahtev.
  • Zahtev se stavlja u red/listu koja treba da bude Thread safe.
  • Korisnik odmah dobija odgovor da se zahtev obrađuje.
  • ThreadPool ima fiksan broj niti koje uzimaju jedan po jedan zahtev i obrađuje.
  • Nit izvršava skriptu i dobija rezultat zadatka,
  • Slanje odgovora serveru se ovde razlikuje u odnosu na prethodni slučaj, ne šalje se kao odgovor na zahtev kao u prethodnom slučaju, već se šalje drugi zahtev serveru.
  • Zahtev serveru bi bio na primer checkTaskResponse, odgovor bi sadržao id korisnika, zadatka, odgovor da li je rešenje tačno.
  • Kada server dobije odgovor potrebno je da unese u bazu i odgovori studentu

• Kombinacija prethodnih predloga

  • U prvom slučaju umesto da server čeka kraj izvršavanja upita, grader odmah odgovori da se upit procesira.
  • Upit se stavlja u red za izvršavanje.
  • Ostatak se izvršava kao u drugom slučaju.