Ben Engber wrote:
> I'm also very curious about this.
>
> What we do here (using GNUJSP) is have a servlet read all the input, do the
> work, and create a bean with all the output variables to substitute. It
> puts this bean in the HttpSession and does an
> HttpServiceResponse.sendRedirect() to the JSP which uses the bean. This
> seems like it would be _terrible_ for performance, not only because it
> involves two separate HTTP requests per page but also because it involves
> completely unnecessary HttpSession operations.
>
The sendRedirect() approach works, but does have negative performance impacts due
to the extra round trip to the client. Howeber, I understand that most
implementations of the 0.91 spec supported callPage(), which I thought worked
like RequestDispatcher does in 0.92, and handles the redirection on the server
side.
>
> Does anyone have any performance benchmarks on this vs. "model 1" vs. the
> standard templating model to which Keith was referring? Does the 0.92
> getRequestDispatcher() stuff address these issues?
>
If you use RequestDispatcher.forward(), the redirect happens on the server side,
and is transparent to the browser. The effort this requires on the servlet
engine's part is very small, so it has basically no impact on performance. (You
can also use RequestDispatcher.include() calls to utilize the same technique to
simulate a server-side-include if you want.)
Remember that in most implementations a JSP page gets compiled into a servlet --
this is very common, but *not* required by the spec -- so (after the first time
compilation) the performance impact of forwarding to a JSP page or forwarding to
a regular servlet is identical. The take-home point, though, is that the cost of
this forwarding is so small that it should not be the basis for deciding on your
application architecture.
Scripting and templating systems that compile into a servlet the first time you
use them will, in general, have performance characteristics equivalent to a pure
servlet implementation of the application, as well as equivalent to a Model 2
based JSP based solution. That is because they all end up executing pretty much
the same thing -- a servlet that pumps out the static HTML code from your
template out of internal character arrays or something, and dynamically generates
the dynamic content that replaces your scripting tags. Choosing among these
types of template/scripting solutions, then, can be based on criteria than
performance. (My personal preference for the standard JSP tags and model 2
application architecture is well known to readers of JSP-INTEREST, but others
might like some of the other script/template solutions. :-)
Scripting and templating systems that interpret your script every time will in
general run a little slower -- but all the weasel words are because the details
*really* depend on which engines you're talking about, as well as the
characteristics of the application itself.
>
> -Ben
>
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
