>I thought we had all that pick crap killed off in the early 80s, I suppose
>your supporting the Lynx browser as well!
>
Now, now, Brian, I doubt he/she *chose* to use it.... Let's not hold
platform restrictions against anybody, even if they are crap... <grin>
>2) The servlet is unlikely to be the problem. Write a standalone java app,
>that performs whatever query is passed into it as an argument, and test the
>query that way. Utilize any JDBC wrapper code your real app uses
(connection
>pools, etc.). This will test your JDBC wrapper code on down, and verify
that
>your query is working as you would expect. If this program is returning
your
>query faster than the servlet, then you can consider the servlet's
>performance to be an issue, but not until this program is executing faster
>than the servlet. Also, realize that caching will effect your performance,
>so if you execute this program after executing the servlet, your tests will
>be invalidated.
>
If nothing else, add a "main()" to your servlet and run it directly from the
command-line; you can always have main() call into your Servlet's overridden
methods and simulate a simple Servlet environment; or, alternatively, just
have main() exercise the same code snippets that the Servlet, executing
normally, would. Either way, Java's ability to run any class' main() method
from the command-line is really cool for unit- and package-level testing.
>3) Logging/Tracing/Debugging messages are key. Your application is going to
>break, but with good logs, you will be able to determine what caused the
>problem and fix it. At a minimum we trace every method that is entered.
This
>gives you an idea what method caused the problem.
>If you have this level of logging/tracing messages, and you timestamp all
of
>them (as I do, all configurable of course), then you can identify what
>method is causing the performance bottleneck. In all cases, my performance
>bottlenecks so far have been related to the database, not the servlet
>engine. Of course, I'm using a different servlet engine than you are using.
>
I second the comment; diagnostic tracing is SOOO critical in a server-side
application, where debuggers aren't always available and can't always
recreate the problem sufficiently. Just to avoid the possibility of a
bottleneck, though, you can have your tracing/logging code check a global
flag (perhaps a setting in a properties file or something) to determine what
level of diagnostic tracing to run at. The C++ community developed this into
an art form--you might take a look (if you came from a C++ background, I
dunno) and see if there's some ideas there that inspire you. (Borland's
Object Windows Library, in particular, had a fairly sophisticated logging
facility, and the GNU Nana system is supposed to be fairly powerful, as
well.)
Brian, I'd be interested in seeing what you've developed for your diagnostic
logging somtime.
>I am having major speed issues. This is my first servlet project and the
>queries take up to 10 minutes to process. Sometimes, my browser times out
>before they are done.
>
I don't know your environment, but there's an outstanding issue with using
TCP/IP sockets on a machine that's not actually connected to the
network--apparently Microsoft's TCP/IP stack implementation can take up to
minutes to do a TCP/IP operation, even if it's just to "localhost"; I did an
RMI project on a laptop for a while, and it was DOG slow for this reason.
The Sun Bug Parade has some info on this.
>Also, we are using JRun Pro w/ IIS 4. I still can't get it installed
>properly. The docs are terrible!! Also, the company offers tech support
over
>the phone w/ 72 hour turnaround. 72 hours??? This is very annoying.
>
As much as I sympathize, I'd not be TOO critical of a policy like that; I've
had tech support calls take up to a week before getting any kind of a
response, from companies with *much* larger employee bases than JRun Pro's.
Usually I've found the best support comes from a company-sponsored mailing
list or bulletin board, where other users can collaborate. They're usually
far more on top of commonly-asked questions and issues than the tech-support
staff are, in my experience. <shrug> Take with a large grain of salt.
Ted Neward
Patterns/C++/Java/CORBA/EJB/COM-DCOM spoken here
http://www.javageeks.com/~tneward
"I don't even speak for myself; my wife won't let me." --Me
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
