aspose file tools*
The moose likes JSP and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSP
Bookmark ""jsp:include" performance implications" Watch ""jsp:include" performance implications" New topic
Author

"jsp:include" performance implications

John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
Hi, I have a JSP file that has a couple of include directives in a forEach loop. For some reasons outside of this discussion, I need to change the include directives to include actions. The code is sort of like the following:

[Before]
c:forEach ...
@ page include="childA.jsp"
@ page include="childB.jsp"
/c:forEach

[After]
c:forEach ...
jsp:include page="childA.jsp"
jsp:include page="childB.jsp"
/c:forEach

There are roughly about 50 iterations for the loop, which means that it's going to be 50 dynamic calls to childA.jsp and another 50 to childB.jsp. The total of dynamic calls is about 100 from the including page, let just call it parent.jsp.

Now I know that all three JSPs, i.e. parent.jsp, childA.jsp, and childB.jsp will be translated into a corresponding servlet class and at the runtime the parent_servlet will call childA_servlet and childB_servlet and the response from each child servlet will be merged into the response of the parent servlet.

What I don't quite know is the performance implications, if any, to convert include directives to include actions.

Will the call to childA_servlet from parent_servlet be essentially the same as the call to childA.jsp from a web browser (of course, minus all the network stuff as the parent_servlet and childA_servlet both reside on the same app server.)?

It seems logical to me that the performance of dynamic includes cannot beat that of static includes. But I am wondering in the real world, is there any real performance difference between 100 static includes and 100 dynamic includes.

I've done some googling and seen some articles claiming that performance difference between the types of includes is negligible.

1.Have there been any serious analysis done in this regard?
2.Any lab tests that support the findings one way or the other?
3.Can the answer to this question be J2EE server implementation specific?

Thanks in advance for the gurus out there.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

"learning always", please check your private messages for an important administrative matter.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

Seems like it would be simple enough to run your own series of tests. Have you tried it?
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
I did do some performance tests and didn't observe any significant performance difference. But since I was not able to conduct any real tests in a very controlled environment where the only variant was the type of the includes while everything else being the same, my tests aren't really that meaningful.

Besides, not only do I want to know the answer to my question is yes or no, more importanly, I want to know why.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

In the face of heavy-duty over-head like network traffic and DB access, the difference in processing the different types of include is noise. Rather than worrying about indiscernible differences in performance, one should use whichever mechanism makes the most sense for the intended usage.
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
It does make sense to think that the performance difference solely caused by the type of include in use is less significant considering all other factors. Honestly I thought the same way myself.

Having said that, any insight into the inner workings of an app server with respect to how the dynamic includes are processed is still greatly appreciated. And the answers can very well be vendor product dependent.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

Originally posted by John Lin:
And the answers can very well be vendor product dependent.

And they will be. The Tomcat source is open for you to inspect.
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
My company's site runs on WebLogic.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

Originally posted by John Lin:
My company's site runs on WebLogic.

Then rather than using the source, you would just have to rely on trying it.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
Originally posted by Jeanne Boyarsky:

Then rather than using the source, you would just have to rely on trying it.


Trying won't shed much light on how exactly the WebLogic app server works internally in processing dynamic includes. I would appreciate your knowledge/insight on this subject if this is your area of expertise; otherwise, I'd look forward to hearing from those who know a little better.

As I have said repeatly, I'm interested in knowing the inner workings of this thingy.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

The problem with knowing the inner workings of a closed source application server is the fact that it is, well, closed source. Your best bet is to read the Servlet and JSP Specifications and hope that BEA followed the specifications in those areas.

http://java.sun.com/products/servlet/download.html


GenRocket - Experts at Building Test Data
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

Which is why I recommended looking at the open source Tomcat code as an example of how this can be implemented. No one except people who work or worked at Weblogic and are willing to violate their employment privacy agreements can tell you specifically how Weblogic works internally.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
As I have said repeatly, I'm interested in knowing the inner workings of this thingy.

I would caution against getting too interested in the inner workings of a server, because what matters is the service provided by the server. It is the important difference between the server and the service. And even if you were to somehow find out how WebLogic Server implements something, are you going to carry out a similar exercise whenever you upgrade? I would say that this is unlikely, and you may even find that decisions made on how a previous version of a server implements something may later become invalid.

As developers, we code to APIs, so what is important is that the server properly implements the APIs. I really won't worry about performance concerning WebLogic Server unless you have some particular reason to be concerned.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
Originally posted by Gregg Bolinger:
Your best bet is to read the Servlet and JSP Specifications and hope that BEA followed the specifications in those areas.

http://java.sun.com/products/servlet/download.html


This is not unreasonable. But the answers are not in the specs. As with all other Java specs, they don't dictate how vendors should implement a particular functionality. In other words, the specs are only about "what" but not about "how". I appreciate your suggestion nonetheless.
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
Originally posted by Roger Chung-Wee:

As developers, we code to APIs...


Absolutely agreed. I certainly won't want my design to be driven by the inner workings of a particular vendor's particular implementation. However, I do want to point out a well-known fact that there are many things that J2EE developers are not supposed to be worried about but in reality they have to especially what it comes to performance related issues.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

Originally posted by John Lin:
In other words, the specs are only about "what" but not about "how".
As web app developers we need not be concerned with the vendor-specific "how".

Originally posted by John Lin:
However, I do want to point out a well-known fact that there are many things that J2EE developers are not supposed to be worried about but in reality they have to especially what it comes to performance related issues.
Hmmm, not so well-known to me. In over 8 years of developing applications to the Servlet and JSP APIs I have never run into a problem, performance or otherwise, that required knowing how a specific vendor implemented a detail of the specifications. Your own experiences may have been different, but most web app developers do not need to know how the vendors implement the specs.

Again, if you are having specific performance problems with how Weblogic implements the include mechanisms, contacting Weblogic support is your best bet for working it out.
John Lin
Greenhorn

Joined: Feb 22, 2008
Posts: 17
Originally posted by Bear Bibeault:
No one except people who work or worked at Weblogic and are willing to violate their employment privacy agreements can tell you specifically how Weblogic works internally.


I have worked for software product vendors as well as for companies that use other vendors� products. I know from my real life experiences from both the provider side and the consumer side that the software vendors such as BEA have every incentive to help the developer communities gain as much in-depth knowledge about their products as possible. The more the developers know about their products, the better they are going to be able to make use of them.

To suggest that wanting to know a bit more about how include actions are processed internally is to expect people to violate their employment privacy agreements is bit a stretch, to say the least. The truth of the matter is that there is so much knowledge that can be shared in the public domain without necessarily violating any either privacy or intellectual property agreement.

I have to say, regrettably, that at this point this thread has been way too much focused on the merit and validity of the questions themselves instead of the answers to those questions. While it�s my strong belief that the questions I have raised are both valid and meaningful ones, I do respect others who may think differently and who have been kind enough to spend their valuable time sharing their thoughts and feedback. It certainly wasn�t my intention to drag people into arguing back and forth about the validity of the questions themselves. Furthermore, I think that any further discussions in that direction won�t serve any purpose and will not lead this thread to anywhere.

Sincere thanks to you all.
[ February 24, 2008: Message edited by: John Lin ]
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by John Lin:
While it�s my strong belief that the questions I have raised are both valid and meaningful ones.


Whether they are valid and meaningful is irrelevant; at least here.
You're asking about the internal workings of a closed source commercial application. This is something that can't be answered here.
The only people who can tell you how WebLogic works internally, are the folks at BEA.

I'm not 100% sure about this, but doesn't WebLogic use Jasper for JSP compilation? I thought I remembered seeing Jasper exceptions in some of the stack traces posted by people here, in the past. If so, you might actually be able to find out what WebLogic does by looking at the Tomcat source.
Jasper is the open source JSP compiler written for Tomcat.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: "jsp:include" performance implications