Forums Register Login

Some performance and scalability related questions

+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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)
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
Choice 4.

Normally, the central cache is sharable amongst clients, thus imply the application scope.
+Pie Number of slices to send: Send
 

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.
Listen. That's my theme music. That's how I know I'm a super hero. That, and this tiny ad told me:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 3774 times.
Similar Threads
Why should we use Enity Beans?
Needs to improve the performance of the application
long post IBM.158
What do I need to produce proxy stub
Best Answer
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 08:28:29.