jetty server 12.0.16 limitatore connessioni TCP
36 views
Skip to first unread message
Danilo Santullo
Nov 26, 2025, 3:00:37 AM11/26/25
to JUGMilano - JVM User Group Milano
Ciao a tutti e grazie per avermi accolto.
Domanda:
Sto utilizzando jetty-server-12.0.16
Durante il suo utilizzo, ho necessità che le connessioni tcp siano uguali ai thread interni.
Ho già provato ad applicare il DoSFilter e a scaricarmi dai sorgenti la classe NetworkConnectionLimit
ma entrambe le opzioni sembrano non facciano al mio caso.
Qualcuno di voi si è già trovato in una situazione del genere?
Grazie.
Domanda:
Sto utilizzando jetty-server-12.0.16
Durante il suo utilizzo, ho necessità che le connessioni tcp siano uguali ai thread interni.
Ho già provato ad applicare il DoSFilter e a scaricarmi dai sorgenti la classe NetworkConnectionLimit
ma entrambe le opzioni sembrano non facciano al mio caso.
Qualcuno di voi si è già trovato in una situazione del genere?
Grazie.
Simone Bordet
Dec 8, 2025, 3:49:47 AM12/8/25
to jugm...@googlegroups.com
Ciao,
On Wed, Nov 26, 2025 at 9:00 AM Danilo Santullo
<danilo....@gmail.com> wrote:
>
> Ciao a tutti e grazie per avermi accolto.
> Domanda:
> Sto utilizzando jetty-server-12.0.16
> Durante il suo utilizzo, ho necessità che le connessioni tcp siano uguali ai thread interni.
Perchè?
Questo è tipicamente un errore, perché si basa su un modello
estremamente semplificato (e spesso errato) di come funziona un web
server (e Jetty nel caso specifico).
Puoi spiegare qual è il problema che ti ha portato a pensare che la
soluzione sia "che le connessioni tcp siano uguali ai thread interni"?
> Ho già provato ad applicare il DoSFilter e a scaricarmi dai sorgenti la classe NetworkConnectionLimit
> ma entrambe le opzioni sembrano non facciano al mio caso.
Perché non fanno al caso tuo?
--
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
On Wed, Nov 26, 2025 at 9:00 AM Danilo Santullo
<danilo....@gmail.com> wrote:
>
> Ciao a tutti e grazie per avermi accolto.
> Domanda:
> Sto utilizzando jetty-server-12.0.16
> Durante il suo utilizzo, ho necessità che le connessioni tcp siano uguali ai thread interni.
Questo è tipicamente un errore, perché si basa su un modello
estremamente semplificato (e spesso errato) di come funziona un web
server (e Jetty nel caso specifico).
Puoi spiegare qual è il problema che ti ha portato a pensare che la
soluzione sia "che le connessioni tcp siano uguali ai thread interni"?
> Ho già provato ad applicare il DoSFilter e a scaricarmi dai sorgenti la classe NetworkConnectionLimit
> ma entrambe le opzioni sembrano non facciano al mio caso.
--
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
Danilo Santullo
Dec 11, 2025, 3:37:07 AM12/11/25
to JUGMilano - JVM User Group Milano
Ciao Simone e grazie per le risposte.
Provo ad essere più dettagliato nel nostro specifico caso d'uso.
- Contingentare il numero di client attaccati a Jetty. Nel nostro modello il client si connette, mantiene la connettività sulla quale effettua n chiamate.
- Il timore è questo: avendo più richieste dei processi interni di jetty, queste possano accodarsi e il tempo di elaborazione della singola richiesta venga sommato al tempo di attesa delle richieste in coda.
Esempio: abbiamo 10 thread che girano e 40 richieste. Se non c'è un parallelismo, dopo la decima richiesta, ogni richiesta potrebbe avere un attesa nell'elaborazione e di conseguenza si aumenta il tempo della singola richiesta.
Avendo ogni singola chiamata uno SLA di risposta, non vorremmo come risultato che la risposta sia equivalente a tempo di attesa code + tempo di elaborazione.
- DosFilter non ha fatto a caso nostro per i vincoli temporali che lo caratterizzano, poichè non dobbiamo conteggiare il numero massimo di chiamate al secondo ma dobbiamo garantire che i tempi di risposta siano quelli effettivi di elaborazione
e non sommatorie tra attese ed elaborazione (magari perchè i threads interni sono meno delle chiamate esterne.)
Grazie.
Danilo Santullo.
Simone Bordet
Dec 12, 2025, 2:30:27 PM12/12/25
to jugm...@googlegroups.com
Ciao,
On Thu, Dec 11, 2025 at 9:37 AM Danilo Santullo
<danilo....@gmail.com> wrote:
>
> Ciao Simone e grazie per le risposte.
> Provo ad essere più dettagliato nel nostro specifico caso d'uso.
>
> - Contingentare il numero di client attaccati a Jetty. Nel nostro modello il client si connette, mantiene la connettività sulla quale effettua n chiamate.
>
> - Il timore è questo: avendo più richieste dei processi interni di jetty, queste possano accodarsi e il tempo di elaborazione della singola richiesta venga sommato al tempo di attesa delle richieste in coda.
> Esempio: abbiamo 10 thread che girano e 40 richieste. Se non c'è un parallelismo, dopo la decima richiesta, ogni richiesta potrebbe avere un attesa nell'elaborazione e di conseguenza si aumenta il tempo della singola richiesta.
Quello che descrivi è un modello troppo semplicistico di come
funzionano le cose.
Come prima cosa, se non hai anche 10 CPU cores liberi per processare
le richieste, le tue 10 richieste verranno accodate e saranno in
competizione per il tempo di CPU, quindi stai comunque pagando tempi
di attesa in code.
Se hai scritto la tua applicazione con codice bloccante, quei 10
threads verranno bloccati, deschedulati dalla CPU e altre 10 richieste
possono essere processate in modo concorrente rispetto alle prime 10,
fino a che ci sono threads disponibili.
Se invece hai scritto la tua applicazione con codice non-bloccante,
quei 10 threads verranno liberati e saranno disponibile per altre
richieste.
Se ogni richiesta impiega 200 ms in media, con 10 threads puoi
processare 50 richieste/s.
Ma se hai richieste con tempi di elaborazione diversi (per esempio una
richiesta di "ping" da parte del load balancer -- molto veloce, e una
di processing applicativo -- molto lenta), allora non vuoi bloccare la
richiesta di "ping" neanche se hai 10 richieste applicative che stai
processando.
> Avendo ogni singola chiamata uno SLA di risposta, non vorremmo come risultato che la risposta sia equivalente a tempo di attesa code + tempo di elaborazione.
Ma lo SLA dove lo misuri, al client, or al server?
Se è misurato al client, quali sono le garanzie della rete?
Secondo me, invece di cercare di configurare il server per ottenere
uno SLA lato server, ti conviene fare l'enforcing dello SLA in modo
applicativo.
Scrivi un Jetty Handler oppure un Servlet Filter che fa partire il
timer SLA, che viene cancellato quando la richiesta è completata,
oppure ritorna un errore al client se la richiesta supera lo SLA (o
una percentuale dello SLA, considerando i tempi di rete ecc.).
> - DosFilter non ha fatto a caso nostro per i vincoli temporali che lo caratterizzano, poichè non dobbiamo conteggiare il numero massimo di chiamate al secondo ma dobbiamo garantire che i tempi di risposta siano quelli effettivi di elaborazione
> e non sommatorie tra attese ed elaborazione (magari perchè i threads interni sono meno delle chiamate esterne.)
L'unico modo che hai di garantire una cosa del genere è quello di
avere più CPU cores che threads attivi, e sperare che il GC/JIT non ti
rubi qualche CPU e che tutti i servizi esterni che usi funzionino
*perfettamente* (improbabile).
Se l'applicazione fa uso di altri servizi (file system, JDBC,
databases, chiamate ad altri servizi REST, ecc.), non puoi comunque
garantire nulla, per qualcuno di quei servizi potrebbe essere lento
anche se tu stai processando una richiesta solamente.
Hai provato a guardare QoSHandler:
https://jetty.org/docs/jetty/12.1/programming-guide/server/http.html#handler-use-qos?
Proverei a riformulare gli SLA in modo statistico, fare delle prove di
load testing e vedere come si comporta il sistema, piuttosto che
cercare di configurare il server sulla base di un modello troppo
semplificato che risulterà quasi sicuramente errato.
Fai sapere, l'argomento è interessante :)
On Thu, Dec 11, 2025 at 9:37 AM Danilo Santullo
<danilo....@gmail.com> wrote:
>
> Ciao Simone e grazie per le risposte.
> Provo ad essere più dettagliato nel nostro specifico caso d'uso.
>
> - Contingentare il numero di client attaccati a Jetty. Nel nostro modello il client si connette, mantiene la connettività sulla quale effettua n chiamate.
>
> - Il timore è questo: avendo più richieste dei processi interni di jetty, queste possano accodarsi e il tempo di elaborazione della singola richiesta venga sommato al tempo di attesa delle richieste in coda.
> Esempio: abbiamo 10 thread che girano e 40 richieste. Se non c'è un parallelismo, dopo la decima richiesta, ogni richiesta potrebbe avere un attesa nell'elaborazione e di conseguenza si aumenta il tempo della singola richiesta.
funzionano le cose.
Come prima cosa, se non hai anche 10 CPU cores liberi per processare
le richieste, le tue 10 richieste verranno accodate e saranno in
competizione per il tempo di CPU, quindi stai comunque pagando tempi
di attesa in code.
Se hai scritto la tua applicazione con codice bloccante, quei 10
threads verranno bloccati, deschedulati dalla CPU e altre 10 richieste
possono essere processate in modo concorrente rispetto alle prime 10,
fino a che ci sono threads disponibili.
Se invece hai scritto la tua applicazione con codice non-bloccante,
quei 10 threads verranno liberati e saranno disponibile per altre
richieste.
Se ogni richiesta impiega 200 ms in media, con 10 threads puoi
processare 50 richieste/s.
Ma se hai richieste con tempi di elaborazione diversi (per esempio una
richiesta di "ping" da parte del load balancer -- molto veloce, e una
di processing applicativo -- molto lenta), allora non vuoi bloccare la
richiesta di "ping" neanche se hai 10 richieste applicative che stai
processando.
> Avendo ogni singola chiamata uno SLA di risposta, non vorremmo come risultato che la risposta sia equivalente a tempo di attesa code + tempo di elaborazione.
Se è misurato al client, quali sono le garanzie della rete?
Secondo me, invece di cercare di configurare il server per ottenere
uno SLA lato server, ti conviene fare l'enforcing dello SLA in modo
applicativo.
Scrivi un Jetty Handler oppure un Servlet Filter che fa partire il
timer SLA, che viene cancellato quando la richiesta è completata,
oppure ritorna un errore al client se la richiesta supera lo SLA (o
una percentuale dello SLA, considerando i tempi di rete ecc.).
> - DosFilter non ha fatto a caso nostro per i vincoli temporali che lo caratterizzano, poichè non dobbiamo conteggiare il numero massimo di chiamate al secondo ma dobbiamo garantire che i tempi di risposta siano quelli effettivi di elaborazione
> e non sommatorie tra attese ed elaborazione (magari perchè i threads interni sono meno delle chiamate esterne.)
avere più CPU cores che threads attivi, e sperare che il GC/JIT non ti
rubi qualche CPU e che tutti i servizi esterni che usi funzionino
*perfettamente* (improbabile).
Se l'applicazione fa uso di altri servizi (file system, JDBC,
databases, chiamate ad altri servizi REST, ecc.), non puoi comunque
garantire nulla, per qualcuno di quei servizi potrebbe essere lento
anche se tu stai processando una richiesta solamente.
Hai provato a guardare QoSHandler:
https://jetty.org/docs/jetty/12.1/programming-guide/server/http.html#handler-use-qos?
Proverei a riformulare gli SLA in modo statistico, fare delle prove di
load testing e vedere come si comporta il sistema, piuttosto che
cercare di configurare il server sulla base di un modello troppo
semplificato che risulterà quasi sicuramente errato.
Fai sapere, l'argomento è interessante :)
Reply all
Reply to author
Forward
0 new messages