Tenir l’aplicació ben enroutada no significa què després el enllaç amigable sigui funcional al 100%: si no es dins del context de la aplicació React. Per a aquesta raó s’haurà de dir al servidor HTTP que redireccioni qualsevol petició diferent a la ruta de index a la mateixa què el propi index que executa la aplicació.
En alguns casos com pot ser ASP MVC amb l’extensió de SPA, el propi host IIS o autohost de NET Core es configura per redireccionar aquestes peticions. En NodeJS passa exactament el mateix al desplegar-lo com una aplicació React Client.
En altres entorns no es ben bé així, com pot ser Apache o Azure Static Web Apps.
Apache:
Caldrà crear un fitxer .htaccess pròpi a la carpeta on es situï el build i dins caldrà especificar les següents línies
Revisió gener 2020: Aquesta entrada va ser escrita al 2018 en plena fase de desplegament. Actualment les Azure functions v2 i v3 ofereixen el always on què disminueix dràsticament la latència de les funcions. Les funcions escrites amb Net Framework només poden anar amb V1 que ara mateix està en camí a deprecated.
Des Azure fa un temps els webjobs de les WebApps d’Azure s’estan traslladant a funcions. Això el teu els seus avantatges, com no consumir recursos de les instàncies de WebApp i consumir-ne sota demanda.
Tot és correcte fins que les versions actuals de serveis no ofereixen quelcom bàsic: estar sempre actives. Això és vital qual la funció es dedica a llegir una cua: o pot estar desactiva sempre o pot estar osiosa esperant a respondre. Les Azure Functions al no tenir Always On són el primer cas: desactiva fins que es digui el contrari. Doncs es plantegen dos solucions: (A) fer un pas enrere i tornar a workers o (B) fer un mecanisme de mantenir sempre viu.
La latència de les respostes del encadenat de processos és alt degut al temps de warm up de una Azure Function
La solució A implica desplegar una sèrie de llibreries que tenen ús crític de la CPU a una instància WebApp que ja de per si ja té pics de CPU. Descongestionar la instància de aquests pics és una prioritat.
La solució B implica refórmular el codi de lectura de cues per a que quan a la senyal de vida, una senyal que anomenarem keep_alive. Un altre funció Azure inserirà a la cua cada X (definirem el temps com una variable de configuració per a trobar el rendiment òptim) un missatge de keep_alive que els diferents processos encadenats en cues només hauran de retransmetre de la cua d’entrada a la de sortida.
És una forma de mantenir els processos de la cua ociosos, tampoc és una novetat. Són principis que vaig veure a clustering amb heartbeat/pacemaker o més simples, per evitar que el IIS decidís que era bon moment posar-se en repòs.
El problema és què pot saturar les cues (1), pot sobrecarregar els serveis (2) i pot implicar un consum extra (3). Així que caldrà trobar el equilibri entre mantenir una latència optima: una repetició de la senyal keep_alive que no desajusti el sistema i dispari els costos.
En vermell: un keep alive cada 10 segons, en blau cada 20 segons, en verd cada 30.
Provem 3 períodes per a l’enviament de keep_alive: cada 30 segons, cada 20 segons i després cada 10. La Azure Function té aproximadament un període de 10 segons per a aixecar-se (warm up a actiu) i de repòs molt menor (al acabar ja passa a repòs).
El fet de mantenir-lo a 30 s’aconsegueix que les peticions intercalades entre les senyals de vida passin de pics de 120 a 60. Segueix sent un temps d’espera elevat per al client, que voldria resoldre les peticions en el menor temps possible.
Reduint el keep_alive a 20 segons reduïm els pics a 30 segons. La meitat de la meitat. I a 10 segons aconseguim que els pics es redueixin a menys de 10 segons.
El curiós de tot això és que són processos que a la versió de desktop mai vam aconseguir que arribessin a aquests números. Les Azure Functions amb una bona conjunció de SQL Server i optimització poden arribar a mostrar molt bons resultats.
