[Libri] Recensione libro Release It! parte 4

Capacity

Spassoso racconto introduttivo di una esperienza. Secondo me l'autore ha usato ATG, prodotto commerciale
per siti di commercio elettronico che ho usato anche io in un mio progetto. Nell'introduzione ho scoperto anche
la CONWAY'S LAW ovvero la legge secondo cui il software rappresenta il modello comunicativo che intercorre
tra i suoi sviluppatori. Giunge quindi alle

Due definizioni:
* "Capacity is fundamentally a measure of how much revenue the system
can generate during a given period of time."
*il massimo throughput che un sistema può sostenere per un certo carico mantenendo un tempo di risposta accettabile
per ogni transazione.
Si distingue dalla performance -la velocità di processamento di una singola transazione, misurata in isolamento
o sotto carico- e dalla scalabilità - il cambiamento di throughtput a seconda del carico -.
Il più delle volte è possibile aumentare la capacità tramite opportune modifiche al design del software piuttosto
che aumentando l'hardware.
Come ?

Identificando il collo di bottiglia, il VINCOLO che limita la capacità di tutto il sistema.
Ci sono in gioco le 'driving variables' cioè agenti fuori dal nostro controllo, come il tempo, le richieste degli utenti etc
che influenzano le 'following variables'. Queste possono essere misurate: uso della cpu, della memoria, della banda etc.
Il 'constraint' è il limite rappresentato da una della 'following variables'.

Segue un elenco di antipattern, introdotti con una breve descrizione, tutto buoni consigli che se non conosciuti
non fanno suonare alcun campanello di allarme durante lo sviluppo.
Brevemente:

• il male necessario: i db connection pool. L'ideale è avere un numero di thread pari al numero di risorse. Spesso infatti i thread vengono bloccati all'infinito in attesa della risorsa libera, in tal caso è da considerare il caso di un timeout. I Resource pool servono per eliminare il tempo di setup delle connessioni. Devono essere dimensionati.
  

• in caso di jsp , esse vengono compilate e vanno nella parte di memoria chiamata JVM permanent generation. Se però si disabilita il garbage collector per le classi ( - noclassgc) tale area di memoria può venire saturata.
  

• ajax: la risposta del servizio richiesto deve essere la più snella possibile; quindi meglio json di xml, evitare html and so on. Quando si usa ajax è facile che aumenti il numero di connessioni, in tal caso configurare il web server opportunamente ( parametri maxclient etc...)
  

• sql: evitare di scrivere query complesse a mano in un sistema che ha un orm ; non tanto perchè l'sql generato da un orm è perfetto ma per lo meno ha sempre la stessa struttura. Evitare join su colonne senza index e evitare di trovare con una query un singolo oggetto e ripetere la query ma usare l'sql per tornare collezioni! Carinissimo il test del DBA: se si mette a ridere guardando le nostre query non si va in produzione.
  

• db: valutare gli index, quando sono da mettere e se sono obsoleti, la partizione di tabelle

• rmi: si afferma che è falsa l'idea secondo la quale c'è trasparenza tra chiamate locali e remote. Quando si effettuano chiamate remote meglio evitare di fare molte chiamate all'interno di una singola interazione.
  

• cookie: usarli solo per storare l'informazione circa l'identificazione dell'utente.

...dopo l'elenco di antipattern quello dei pattern:

• Pool connection: da usare perchè elimina il tempo di set up di una connessione.

• Uso accurato della cache:

- devono avere una dimensione massima di memoria allocabile altrimenti crescendo troppo fanno sì che il
garbage collector sia sempre impegnato nella ricerca di memoria libera
- misurare l'hit rate perchè se è molto basso non ha senso usare una cache
- evitare di mettere in cache oggetti la cui generazione è molto rapida
- usare le SoftReference per mantenere un riferimento agli oggetti per aiutare il garbage collector
- ogni cache deve avere un meccanismo di rimozione oggetti quando i dati sorgente cambiano: ogni cache
deve essere svuotata prima o poi

• Precompute Content. Esempio delle categorie merceologiche di un sito di commercio elettronico, il cui elenco cambia di rado e che quindi non avrebbero bisogno di essere generate dinamicamente ad ogni page request. Meglio crere un meccanismo di generazione di frammenti html da includere, così come fa Slashdot. Se esistono politiche di personalizzazione dei contenuti per utente non ha senso.
  

• monitorare il garbage collector ( passando come argomento -verbosegc in java)