• Post Reply Bookmark Topic Watch Topic
  • New Topic

Some performance and scalability related questions  RSS feed

 
Fatema Moosa
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Please could you help me with these performance related questions

1) Your company has recently released the first version of a company's web site. The application is experiencing severe performance problems on the production box.
Which one of the following is NOT going to have a positive effect on the performance of the application?
Option 1 Precompiling JSPs.
Option 2 Increasing the number of connections in a connection pool.
Option 3 Packaging custom actions in a single jar file.
Option 4 Reducing verbosity of a logging subsystem.
Option 5 Disabling shrinking in a connection pool.

I think right answer is Option 3?

2) Your application must frequently display data for 3,000 tickers. Each ticker has approximately 20 financial ratios represented as double values.
Referring to the scenario above, which one of the following will result in the fastest response time?
Choice 1 Go to the database for each client's request to read 3,000 lines (one line per ticker).
Choice 2 Pre-generate and store pages in the database in the compressed format.
Choice 3 Create a central cache of ticker data, and put a deep copy of the cache in each HttpRequest.
Choice 4 Create a central cache of ticker data and access it from various pages.
Choice 5 Create a central cache of ticker data, and put a deep copy of the cache in each client's session; access that copy from various pages.


3) How can storing session information in a Session Bean be more scalable over storing session information in HttpSession?

Choice 1 Session Beans can use container managed persistence.
Choice 2 Session Beans can be used by multiple client threads.
Choice 3 HttpSession requires use of cookies or URL rewriting.
Choice 4 Session Beans can survive a server crash.
Choice 5 Session Beans can be activated/passivated.

I think Choice 5 is the right answer?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37254
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with you for #1. For #3, it's arguable. HttpSessions can essentially be passivated if you use session persistance (the session is stored in a database)
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, the question #3 was "what's more scalable". So I'd have to say Answer 2. But it's a trick, since HttpSession and EJB Session don't refer to the same thing.

An EJB session is a general information repository, freely sharable by multiple users and by default existing for the life of the container.

An HTTP session is a repository for information shared between a single user's browser instance and the server. Its default lifetime is set by the application's web.xml.

Because an HttpSession object is not sharable - one must be created for each application user, it doesn't scale as well as Session EJBs, which are specifically designed to be shared.
 
Fatema Moosa
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

Thanks for your reply..
Your answer and the explanation given makes a lot of sense.
Do you have any clue what could be the answer to Question #2?
 
Jerwin Louise Uy
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Choice 4.

Normally, the central cache is sharable amongst clients, thus imply the application scope.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fatema Moosa wrote:
Do you have any clue what could be the answer to Question #2?


I'm concerned if you don't think this one is very obvious.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!