• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Isnt this so inefficient?  RSS feed

 
Ranch Hand
Posts: 1162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Each client gets a separate thread for each request and the container allocates new request and response objects".

So if I surf to a website and hit reload 5 times I have basically spawned 5 threads on the server and 10 request and response objects?
 
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arvind Birla,

Lets discuss things from server end:
What you do think server has to do ?
What I think is : Server has to responde for each request and it does n't know what whether you are reloading or requesting from new browser window.

from client end we have browser chache.
I don't know whether it helps for dynamic pages like jsp,servlets.

Any body with good understanding on this, please post.
Thanks in advance.
 
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So if I surf to a website and hit reload 5 times I have basically spawned 5 threads on the server and 10 request and response objects?

Although you might think they'd be the same, each request/response cycle could in theory generate different content in both directions. For eaxmple, your ISP might use a different proxy on each request so the HTTP headers are different (making the ServletRequest distinct), and the page returned might contain some time-dependent functionality (making the ServletResponse distinct). It therefore makes sense that the request and response objects might be different; further, you wouldn't want two entirely separate requests to share the same object even if the request appeared identical as you'd then also be sharing request-scoped attributes between two different requests (highly undesirable - use session-scoped if that's your requirement). Since there's really no way of knowing what the response will contain without doing all the dynamic execution, there's no obvious way (that I can see) to sensibly optimise that any further.

On the matter of threads, the container has to do work for each request to execute all the code in filters, servlets and JSPs, in theory simultaneously processing all the requests it can that come it at (almost) the same time. You need to use a thread model for each active request. Note I said "active request" - containers could pool threads so they stay alive at the end of one request/response cycle and use them again later. This avoids the overheads of starting a new thread for each request while still threading incoming requests, at the expense of some memory being used to maintain the pool.

At least threads are lightweight! Apache starts multiple processes per server with far greater overheads than a simple thread, and each of those processes then spawns many threads. A typical max setting for the number of processes is 5-10, so in theory that means for each of your five requests there would be 5 processes running, which is significantly less efficient that the equivalent number of threads in a single process. However, running multiple processes in parallel makes the server more stable for large numbers of requests (e.g. a crash of a single request only terminates one process, which can be restarted, and not the entire server!).
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!