Simone wrote:
> La connect come riportata da curl e la TCP connect quindi SYN/SYN+ACK/ACK
Sorry, io rispondevo in merito a questa connect, di cui l'OP parlava:
> 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]?
Purtroppo quando si scrive dal telefono non c'e molto tempo/spazio per
editare :)
Come ho detto, ripeterei il test con http: in quella situazione la
time_appconnect dovrebbe essere zero. Io farei quel controllo per escludere
altri "partecipanti": se dopo un test con http leggi zero, allora questo ti
conferma che e' veramente l'handshaking ssl. Per me e' sempre molto
importante essere assoutamente certi del problema, prima di partire con le
soluzioni :)
Comunque, seguendo la successiva osservazione di Simone sul GC, stai
terminando l'https in java o su un apache/nginx? Perche' apache/nginx me li
ricordo molto stabili come performance e non affetti da pause che invece
potresti avere terminando sul tuo app server java.
In generale, meglio esprimere queste condizioni in "percentili", comunque,
cioe' (come credo abbiano gia' suggerito) "il 99.9% (o quello che ti pare)
delle connessioni dovranno essere yadda yadda yadda": tutti lo fanno, e'
normale.
Ciao,
Bruno
On 28 February 2018 at 13:03, Simone Bordet [email protected]
[it-torino-java-jug] <[email protected]> wrote:
>
>
> Ciao,
>
> 2018-02-28 13:51 GMT+01:00 bruno bossola [email protected]
> [it-torino-java-jug] <[email protected]>:
> > A me puzza un po', nella connect c'รจ un po'di tutto.
>
> La connect come riportata da curl e la TCP connect quindi SYN/SYN+ACK/ACK..
>
> Cosa altro pensi che ci sia ?
>
> --
> 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
>
>
