Molto interessante questo thread. Aggiungo al commento sui "300" di Simone che non ha molto senso dire che *tutte* le chiamate devono eseguire entro 300ms. Ha più senso dire che X% delle chiamate deveono eseguire entro 300ms. Se nel tuo caso sei già a X=99.99%, forse questo risultato potrebbe essere sufficiente (non so, dipende da qual'è la ragione per cui non puoi tollerare molti ritardi.) Passare da 99.99% a 99.999% potrebbe costarti, invento, magari 10gg di lavoro. Passare da 99.999% a 99.9999% potrebbe costare 1000 giorni di lavoro di cui 10 di consulenza di Simone Bordet. Il costo giustifica il risultato? Solo il cliente, che sa qual'è la vera ragione dietro il requisito, può dirtelo.
2018-02-28 14:04 GMT+01:00 Simone Bordet [email protected] [it-torino-java-jug] <[email protected]>: > > > Ciao, > > 2018-02-28 13:03 GMT+01:00 Alessio Santacroce > [email protected] [it-torino-java-jug] > <[email protected]>: > > > > > > > > Ciao a tutti, > > > > Questa non e' proprio una domanda su Java, ma so che ci sono qui molti > esperti di servizi REST e problemi di rete che magari mi possono dare una > buona idea :-) > > > > Sviluppo un servizio REST su protocollo HTTPS. > > Ho come vincolo che le api devono rispondere entro 300 ms. > > Molto aggressivo. > Ti basta una GC un po' più lunga del solito e sei già fuori. > Aggiungi un network roundtrip e sei fuori di parecchio. > Posso chiedere il perché di questo limite così severo ? > Puoi anche rispondere che arriva da uno che si è svegliato il mattino > dopo aver visto il film "300" e gli sembrava un numero giusto. > > > La maggior parte delle risposte finiscono in tempo. > > Una percentuale, in genere intorno all' 1 per mille, no :( > > > > Ho misurato che spesso gran parte del temp e' perso per la connessione > ed in particolare per handshake SSL/SSH. > > > > Per esempio: > > > > curl https://xxx/mio-servizio -w "@curl-format.txt" > > > > time_namelookup: 0.060681 > > time_connect: 0.061517 > > time_appconnect: 0.168877 > > time_pretransfer: 0.168905 > > time_redirect: 0.000000 > > time_starttransfer: 0.171531 > > ---------- > > time_total: 0.171547 > > > > > > Cosa fareste per ridurre il time_appconnect [The time, in seconds, it > took from the start until the SSL/SSH/etc connect/handshake to the remote > host was completed]? > > Devi assicurarti di avere abilitato (client e server) TLS session > resumption. > Questo riduce i roundtrips per il TLS handshake da 2 a 1. > Se puoi usare TLS 1.3, supporta alcune feature sperimentali come zero-RTT.. > > L'altra cosa da non sottovalutare è quella di fare il caching delle > connessioni TCP che a loro volta richiedono 2 roundtrips. > Conviene aprire le connessioni all'inizio e cercare di tenerle aperte > il più a lungo possibile per evitare il costo di aprirne di nuove. > Un'altra feature sperimentale è quella di usare TCP Fast Open. > > Un buon sommario: > https://blogs.windows.com/msedgedev/2016/06/15/building- > a-faster-and-more-secure-web-with-tcp-fast-open-tls-false- > start-and-tls-1-3/ > > Le features le devi poi abilitare in base alla piattaforma che usi. > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > >
