Page Comparison

Profiling results

Jprofiler shows that short of processes the CPU power going toward filter RequestFilter processing for the Sakai portal, most of the proceessing processing required to handle a request (to view a topic) is taking place in DiscussionForumTool.getDecoratedTopic(). 40% of the request is processed by portal classes and the rest of the stack does little with the remaining 60% until this methodthe call to getDecoratedTopic, (2.5% in FilterChain.doFilter() a javax.servlet package class, and about 3% of the remaining in displayTopicById).

Thus the remaining processing (.6 * .975 * .97 = ~57%) takes place in getDecoratedTopic
For these tests, a typical processing time for the request was 13 seconds. So roughly 7400 milliseconds (ms) were in this method.

Within this method (getDecoratedTopic) almost all the muscle is used in forumManager (service) calls:

• 26% is in getTopicByIdWithMessages (about 2000 ms)
• 26% is in hasPreviousTopic (2000 ms)
• 17.3% is in another invocation of hasPreviousTopic (1280 ms
• 15% is in hasNextTopic (1110 ms)
• 13.6% is in another invocation of *hasNextTopic * (1006 ms)

Both hasNextTopic and hasPreviousTopic are full scans of the forum's topics in their stored order. The scan compares the incoming/supplied topic with each iteration value. Upon a match, hasPrevTopic returns true of the previous iteration value (topic) is not null and hasNextTopic returns true of the next iteration value after the match is not null.

...

1. assuming that a given topic is in the forum at all, the result from hasPreviousTopic will always be "true" after the first iteration.
2. the result of hasNextTopic will always be"true" unless it is the last topic
   possible fix: change loops to...

   Code Block
   title for hasNextTopic()
   return (topics.size()>1 && !((Topic)topics.get(topics.size()-1)).equals(topic));

   Code Block
   title for hasPreviousTopic()
   return (topics.size()>1 && !((Topic)topics.get(0).equals(topic));

getDecoratedTopic

1. save the results of previous invocations at the least. This should alone reduce CPU load spent in the parent method by 50% and response times by about %30 (4 seconds)
   possible fix: save results of the above to method calls.

results of changes:

48% of cpu time spent in getDecoratedTopic is in hasNextTopic
39% of cpu time spent in getDecoratedTopic is in hasPreviousTopic
total response time decreased to as much little as 40%

Load testing should reveal real numbers.