2015-01-04 9 views
16

In che modo un singolo servlet gestisce più richieste client in arrivo sotto forma di richieste utente? Sulla base del modello di progettazione singleton so che si ottiene una singola istanza di servlet creata, ma come fa un singolo servlet a gestire milioni di richieste. Confuso anche per quanto riguarda il threading.In che modo un singolo servlet gestisce più richieste dal lato client

Anche le specifiche o le impostazioni del browser sono utili qui per inviare le richieste o generare i thread inviati per le richieste.

È lo stesso per tutti i framework o si differenzia per esempio puntoni v/s molle?

+1

I servlet sono raggruppati, non c'è solo una singola istanza alla volta. – meskobalazs

+0

Si potrebbe dare un'occhiata a [pool di connettori] (http://docs.oracle.com/cd/E23507_01/Platform.20073/ATGInstallGuide/html/s0902tomcatconnectorthreadconfigurati01.html) per esempio. Aiutano a gestire diverse richieste attraverso il threading. –

+2

@AlexanderTorstling ti stai sbagliando completamente. Un servlet è un singleton ed è condiviso tra tutte le richieste. Ogni richiesta viene servita da un thread e le richieste simultanee vengono quindi servite da thread simultanei, ciascuno dei quali chiama contemporaneamente lo stesso servlet. –

risposta

11

I framework Struts/Spring sono in realtà scritti sopra le specifiche Servlet, quindi non importa ciò che si utilizza al di sotto di esso. Servlet.

Hai ragione, viene creato solo singola istanza di Servlet, ma tale istanza è condivisa tra più thread. Per questo motivo non dovresti mai avere stati mutabili condivisi nelle tue Servlet.

Per esempio avete seguenti servlet mappato http://localhost/myservlet

class MySerlvet extends HttpServlet { 

    public void doGet(HttpServletRequest req, HttpServletResponse res) { 
      // Get Logic 
    }  
} 

Il server Web avrà qualcosa di simile (non necessariamente lo stesso) nel suo codice.

MyServlet m = new MyServlet(); // This will be created once 

// for each request for http://localhost/myservlet 
executorService.submit(new RequestProcessingThread(m)); 
20

Ogni richiesta viene elaborata in un thread separato. Questo non significa che Tomcat crea una discussione per richiesta. C'è un pool di thread per elaborare le richieste. Inoltre c'è una singola istanza per ogni servlet e questo è il caso predefinito. (Some more information). Il servlet deve essere Thread Safe.

enter image description here

Se il servlet implementa SingleThreadModel interfaccia, ogni uso filo un'istanza separata di servlet. SingleThreadModel is deprecated, Non usarlo.

SingleThreadModel

ho fatto questa risposta come wiki comunità.

+0

Quindi, in questo caso, qual è il meccanismo alla base di questo scenario ?. Se non usiamo SingleThreadModel, il servlet non è thread-safe, come possiamo risolvere questo problema? – xtiger

+1

@xtiger: Esistono molti modi per rendere il servlet sicuro per i thread. Ad esempio, se non si usano variabili definite nello scope di classe, sarà sicuro per i thread. –

+0

@Ali Sepehri.Kh cosa intendevi per "Ho fatto questa risposta come wiki della comunità". ? – Dedyshka

2

Non creare più istanze di servlet. Il motore servlet crea un thread separato per ciascuna richiesta (fino a un numero massimo di thread) La performance è correlata al numero di thread, non al numero di istanze del servlet.

Ad esempio, se sono presenti 1000 richieste e il numero massimo di thread che possono essere generati dal servlet è 100, si verificherà un peggioramento delle prestazioni.

Per evitare questo problema, è possibile utilizzare il bilanciamento del carico mettendo più server dietro un servizio di bilanciamento del carico. Il servizio di bilanciamento del carico deve essere configurato per "indirizzare" le richieste a uno qualsiasi dei server in base a diversi parametri/impostazioni (distribuzione round robin, distribuzione del carico, ecc.). Maggiore è il carico necessario, maggiore è il numero di server da aggiungere. Tuttavia, questo invia tutto il traffico attraverso il servizio di bilanciamento del carico, quindi è importante che sia ridondante e sicuro da failover.

Problemi correlati