Optimizacija API-ja

Snujem lasten API, ki se mora obnašati vljudno do nekje 10k klientov naenkrat. Podatke shranjujem v MySQL, nato pa se do njih dostopa preko PHP skripte, ki potegne potrebne podatke iz baze in jih pošlje nazaj v JSON obliki (nestisnjeno okoli 700kB).

Trenutno sem zadevo zoptimizriral z

* memcached, za zmanjšanje števila dostopov do baze
* ob_start('ob_gzhandler'); v PHP skripti, ki poskrbi, da se JSON pred pošiljanjem stisne (v kolikor so prisotni headerji ki to naročijo) - rezultat je velik 100kB

Glede na to, da so samo 3-je možni pathi tega APIja (torej 3 kombinacije podatkov), razmišljam, če ne bi bilo bolje narediti cron skripto, ki mi podatke recimo vsako minuto shrani v stisnjen JSON, klienti pa bi nato dostopali direkt do te datoteke, namesto do PHP skript. V tem primeru bi se rešil ukvarjanja z memchached in gzippanjem json podatkov za vsak zahtevek posebej.

Sliši se super, vendar mi je sumljivo da v divjini ne vidim takšnih pristopov. Morda zato, ker je v večini primerov potrebno imeti token, ki ga je na koncu vseeno fajn zverificirati, preden odpošlješ podatke? No, v mojem primeru to ni potrebno. Je še kakšna druga slabost tega pristopa?

* ob_start('ob_gzhandler'); v PHP skripti, ki poskrbi, da se JSON pred pošiljanjem stisne (v kolikor so prisotni headerji ki to naročijo) - rezultat je velik 100kB

Boljsi pristop bi bil konfiguracija webserverja da to počne avtomatsko s html/text/json..

Glede na to, da so samo 3-je možni pathi tega APIja (torej 3 kombinacije podatkov), razmišljam, če ne bi bilo bolje narediti cron skripto, ki mi podatke recimo vsako minuto shrani v stisnjen JSON, klienti pa bi nato dostopali direkt do te datoteke, namesto do PHP skript. V tem primeru bi se rešil ukvarjanja z memchached in gzippanjem json podatkov za vsak zahtevek posebej.

Sliši se super, vendar mi je sumljivo da v divjini ne vidim takšnih pristopov. Morda zato, ker je v večini primerov potrebno imeti token, ki ga je na koncu vseeno fajn zverificirati, preden odpošlješ podatke? No, v mojem primeru to ni potrebno. Je še kakšna druga slabost tega pristopa?

Pri klasični spletni strani bi se temu reklo "page cache", prvi response se generira s phpjem in shrani na disk, naslednji requesti gredo popolnoma mimo phpja in se servira direkt generirana datoteka, dokler cache ne poteče. Praktično loh vidiš takšno implementacijo v wordpress + w3 total cache/wp super cache. To se uporablja kar precej, pohitritev je občutna..

Varnish ima specializiran jezik, v katerem lahko spišeš točno tak medpomnilnik, kakršnega potrebuješ (ki razveljavi podatke v medpomnilniku, ko pride do spremembe podatkov v bazi - to lahko načeloma dosežeš tudi z MySQL triggerjem, ki lahko trivialno pošlje unix signal eksternemu procesu, ki potem poskrbi za izgradnjo novih podatkov v medpomnilniku) in vključuje že vse prvine, ki ti bodo pri tem prišle prav.

Vsak pull je slabši od pusha, seveda pa drži, da je lahko dovolj dober, zato (in ker implementacija ni težavna) sem omenil trigger.

No ja. Mogoče z dodatno konfiguracijo.

po moje bi tam lahko del strani, ki ni košarica potegnil iz cache-a, košarica pa dinamično zgeneriral. najbrž so že pogruntali rešitev za to, me pa zanima kako, če kdo ve.

Košarice se ne kešira. Tudi nima smisla pol/pol delat ker bo uporabnik v vsakem primeru cakal da se zgenerira dinamičen del.

MrStein je 2. sep 2018 ob 16:31 izjavil:

Tisto je per request (razen če kaki smart cache to naredi le enkrat).

To je po mojem peanuts v primerjavi z vsem drugim kar se dogaja.

Jaz bi stvar naredil tako, da bi cron skripta generirala staticne datoteke, potem bi pa ze nginx-u povedal, da naj servira statiko, tako se php niti ne bi poganjal. Druga varianta je, da bi vse skupaj prepisal v Go in tam naredil nek caching check, ki clienta preusmeri na statiko ali pa na novo zgenerira output in ga servira, ce je cache expired.

Že sam PHP je pri tem problematičen. Hitrejši je kakšen .net core ali pa nodejs