Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Profiling results

Jprofiler shows that the CPU power going toward RequestFilter processing for the Sakai portal, most of the 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 the 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.

Possible optimizing

hasNext and hasPrevious

  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...
    for hasNextTopic()
    return (topics.size()>1 && !((Topic)topics.get(topics.size()-1)).equals(topic));
    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 this better.

  • No labels