>
> L'applicazione e' su AWS, Il client si connette ad un ELB e c'e' anche un
> nginx di mezzo
>
..
Okay, se semplicemente provi a pingare una pagina statica, su nginx (senza
introdurre nel filone la tua app) che succede? Stessi risultati? (assumo
che termini l'SSL su ELB)
Ciao,
Bruno
2018-02-28 23:03 GMT+00:00 Alessio Santacroce [email protected]
[it-torino-java-jug] <[email protected]>:
>
>
> Grazie a tutti per le osservazioni...
>
> Il mio servizio viene chiamato da un altro servizio back end.
> Non so bene come sia stato scelto il numero 300, si vede che sembrava un
> buon compromesso tra "dare abbastanza tempo al servizio" e il "non
> ritardare troppo" la risposta.
>
> Non ho visto bene il client http che usano, ma presumo che che cerchino di
> riusare le connessioni.
> Avevo pensato anche ad usare websocket, e' piu' complicato farci delle api
> ma dovrebbe essere comunque piu' veloce, credo. Comunque l'idea dei
> websocket non e' piaciuta.
>
> Per rispondere Bruno...
> Confermo che se uso curl contro un server http non sicuro il tempo
> di time_appconnect e' sempre zero.
> L'applicazione s' su AWS, Il client si connette ad un ELB e c'e' anche un
> nginx di mezzo.
>
> Dagli ultimi test che ho fatto, la percentuale delle chiamate piu' lunghe
> di 300 ms e' circa una su 10,000
> Spero possa bastare
>
>
>
>
> 2018-02-28 21:02 GMT+00:00 Uberto Barbini [email protected]
> [it-torino-java-jug] <[email protected]>:
>
>>
>>
>> Hai ragione, anche Http1.1 ha le persistent connections. Pero' in pratica
>> con un normale client http configurato default non riusi le connessioni,
>> almeno noi avevamo provato e c'era l'handshaking tutte le volte.
>> Siccome quel codice non era in mano nostra ZMQ ci ha risolto il problema..
>> Non dovevamo parsare nessun messaggio, dato che tutta la richiesta era
>> contenuta nel url rest.
>>
>> Uberto
>>
>> 2018-02-28 20:16 GMT+00:00 Simone Bordet [email protected]
>> [it-torino-java-jug] <[email protected]>:
>>
>>>
>>>
>>> Ciao,
>>>
>>> 2018-02-28 21:04 GMT+01:00 Uberto Barbini [email protected]
>>> [it-torino-java-jug] <[email protected]>:
>>> > Si intendo ZeroMQ. Allora nel nostro caso avevamo clienti occasionali
>>> in rest su http e clienti "speciali" a cui dovevamo assicurare la risposta
>>> in 20ms. Se rispondevamo dopo perdevamo l'affare, quindi soldi persi.
>>> > I clienti speciali aprivano una connessione con ZMQ (forse oggi
>>> useremmo kafka, non so) e poi continuavano ad usarla per ore facendo tutte
>>> le richieste che volevano, senza riconnettersi o fare handshaking perche'
>>> la connessione restava su.
>>> > La stessa cosa la puoi anche fare con Websocket o Http/2.
>>>
>>> E anche con HTTP/1.1.
>>> La differenza con ZeroMQ dovrebbe essere solo sul framing (cioè sul
>>> costo di fare il parsing di un "messaggio").
>>>
>>> --
>>> 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
>>>
>>
>>
>
>
