Moderator (MDR): MDR-lisa
Guest Speaker (SPK): SPK-kluge and SPK-connie
MDR-lisa: Hi, everyone. My name is Lisa Stapleton, and I'm your moderator today. I'm here with Kevin Kluge and Connie Weiss, who are our JavaSoftTM experts on server issues, including JavaServerTM and performance tuning. Feel free to ask questions at any time. There's a lot going on in the server world, lately. Last month, the number of JavaTM Web Server downloads hit 10,000, and more than 100 companies are already running it on their production web sites. And some of you might have seen Kevin's article on performance tuning on the JDC and have questions about it.
zoltar: Hi Kevin and Connie. Congratulations on a fine product (JavaServer). We actually use it for a production web site, making exclusive use of Java servlets. Our benchmarking showed that JavaServer is faster than Netscape when running Java servlets. What's your secret?
SPK-kluge: We spent several months tuning the performance of our server, including the basic servlet-dispatch mechanism. The NSAPI plug-in that we provide for Netscape hasn't been tuned as much. We have ongoing discussions with Netscape about the use of servlets in their server. As for secrets, you should check out the article I wrote for the JDC. Many of my secrets are there. One thing we did in this specific area was to put a state machine in the server; this state machine tracks the lifecycle of a servlet. It uses as little synchronization as possible. I've generally found that the individual synchronization operations really aren't that expensive but contention on them can be, and of course that limits scalabilty.
danpel: In the near future I'm going to build a site
that must assist government organizations and hospitals in electronic communication. At this time I don't know the load of this coming site. But one thing is for sure—it MUST be quite scalable. Are there any big commercial sites running JavaServer and Servlets therein, and are they happy about that? My concern is not to run into performance problems later on.
SPK-connie: Salomon Brothers in New York have gone into production with an intranet solution using the Java Web Server. This not only highlights the "large corporation" but also the security needs that come along with any production site. They have been very happy with the performance and the scalability. We are also working with another large New York company to get their Internet site going with the Java Web Server in mid-September. We'll definitely be using them as a reference site as a large company using the Java Web Server, so you'll be hearing about it soon.
MDR-lisa: Connie, what are some of the upcoming releases and developments that people can expect in the next few months?
SPK-kluge: With regard to performance and scalability, you could also check out http://www.specbench.org/osg/web96/results/
res97q3/web96-970630-01968.html That has our published SPECWEB96 number. We're still improving the server's performance, and we're working with the JDK group to make JavaSoft's JDK a more scalable development platform. We're also going to be releasing a servlet benchmark soon. This servlet benchmark measures how many servlet requests a server can handle per second and their latency. I can post some preliminary results here today if people are interested. Of course, the type of servlet matters. We currently have two servlets to benchmark. One does nothing—it just returns immediately, and it acts as a baseline. The other writes out ten 80-character lines in its service method. We're also comparing these servlets to other native server-side content-generation methods, like NSAPI and ISAPI. Does anyone have any particular type of servlet that they think benchmarking would be useful?
MDR-lisa: And while Connie is typing her answers, she and Kevin have some questions for you all out there. What are some of the enhancements and new features you folks would like to see in the server world?
danpel: Being new to Java and not having the overall picture, I can't help thinking if there are any drawbacks to using Java Web Server instead of, for example, NS Enterpise—are there any? With the Java Web Server everything just LOOKS so nice and easy :-)
SPK-connie: We really believe that it "looks so nice and easy" because it is!
Java is a wonderful language in which to develop in and the servlet API does make extending the Java Web Server very straightforward. And you get additional benefits as well. While we hope that you will choose the Java Web Server over all others, the code you write to develop servlets can be used on any of the other major web servers (IIS, Apache, Netscape) using our JSDK. So your code is easy to write, portable, and easier to maintain. That says a lot when you compare it to CGI (Computer Graphics Interface).
zoltar: I will read your article, Kevin. I know performance is the major concern for Java. We have a large application that we cannot release because of performance and bugs in AWT. Do you or Connie think that things like JIT's and HotSpot will solve our problems or are there things we should do now to improve performance, especially in a GUI application?
SPK-kluge: Zoltar, I think I'm going to pass on that—I don't know much about tuning GUI applications, or about AWT. I can say that most of the GUI applications I have seen generate a lot of garbage from Object allocation.
SPK-connie: Our 1.0.1 bugfix release is now available for immediate download from jserv.javasoft.com. We are currently working on our 1.1 release which will have support for HTTP 1.1 as well as other enhancements. I can't give a release date yet, but we will have it out as soon as possible.
SPK-kluge: Are people familiar with the Java Server Toolkit product? It is a source-code product that provides a set of classes that make writing new servers/services a lot easier. Would anyone be interested in a binary release of this product?
splante: In the beta version of JavaServer, there was an HTML class. Is that going to be reintroduced?
SPK-connie: We have plans to reintroduce the HTML class as a part of our 1.1 release.
danpel: I don't know if you are the right people to ask, but here it goes. When will Netscape support JDK 1.1 in servlet technology?
SPK-connie: We have an ongoing dialog going with Netscape to get the JDK updated and incorporated in their release.
splante: kluge, I was under the impression that an upcoming version of the JavaServer would be built on, and include, a binary version of the Server Toolkit. Is that true? If so, how's that coming?
SPK-connie: I'll take that for kluge. The Java Web Server is built on a very early version of the Java Server Toolkit. We do have plans to release a binary version of the Toolkit, but it will be separate from the Java Web Server.
danpel: A comment on connie's answer to one of my former questions. If I understand this correctly, can I write servlets using the 1.1 API, and just by using your JSDK, they will run in NS Enterprise too?
SPK-connie: Yes, that is correct.
ingala: The JWS 1.0.1 has fixed the VeriSign certificate problem, but there are still problems of getting SSL to work, because none of the browsers are able to communicate with the server (uncommon cipher suite problems). What are your comments about SSL and use of VeriSign certificates?
SPK-connie: Hmm, this doesn't make sense to me because I know of several sites that are using SSL and VeriSign certificates (Salomon Brothers being one of them). Have you written the support list, jserv-interest@java.sun.com about the problems you're having?
JoeSam: The performance article on JDC seemed to generally address the same issues we should be familiar with in other languages. Do any techniques strike you that are more Java-specific?
SPK-kluge: Some of the more Java-specific things have to do with the JDK, and some from the language. Here are a few, some from the article, some not:
java.util.Hashtable—lots of functionality, but high cost esp. wrt. synchronization on get operations
- j
ava.lang.String.hashCode—broken for long strings. will be fixed soon. :-)
- synchronized keyword causes stricter than two-phase locking.
Consider this:
At the call to x, you might be able (conceptually) to drop the lock on lock a. But, the Java language won't let you. That can be a real problem. You could write your own lock classes to fix this (like a Mutex class), but you would end up using wait/notify in the case of contention. Wait/notify is really slow. I've seen condition variables be slow on threads packages, but Java wait/notify operations seem to be especially slow. One other thing is that optimizing for different VMs is difficult. VMs from different vendors can have different tuning characteristics. I hope this problem will get better, but I'm not optimistic—I'm hoping for some better analysis tools to make solving problems easier.
JoeSam: It is slowly striking some of us that distributed objects via RMI must be capable of handling multiple threads and users. Are there any techniques that might improve performance or servicability there?
SPK-kluge: I have heard mixed reviews of RMI performance, although I haven't investigated it personally. So I can't recommend any techniques. One thing that I can say is that we have thought about migrating the RMI server base to use our Server Toolkit. This would allow the RMI product to take advantage of all the server-wide performance/scability improvements that we've made.
sboyle: A followup question on the Server Toolkit—is this the same as the Servlet Toolkit? Or will this allow a person to develop services on top of the core server?
SPK-connie: No, the Servlet Toolkit (known as the JSDK) is free and available for download from jserv.javasoft.com right now. The Server Toolkit is a framework of APIs for creating network services that use servlets as "building blocks." With the Server Toolkit, you get support for connection management, thread management, security, and administration. To give you an example, we used an early version of the JavaServer Toolkit to write our Java Web Server. We combined several servlets (file, cgi, and all the others you see in the admin tool) to build the Web Server Service. With the JavaServer Toolkit, system programs can write other network services using the Toolkit APIs. Something to note is that the Toolkit is protocol-independent, so we are using it inhouse to develop services for the NC (Network Computer) as well. Services written by the Toolkit then do not have to be HTTP-bound, but can use any protocol the developer needs to implement his or her service.
danpel: If the Java Web Server is to be used in commercial applications, are there then any fees to be paid?
SPK-connie: Yes, the Java Web Server is $295 with SSL and $95 without SSL for commercial use. It is free for noncommercial use. Right now, it is under a 120-day evaluation period, so no fees are due immediately.
splante: When you release the binary version of the Server Toolkit, will we be able to use the session tracking and page compilation features with the (then) current version of JavaServer?
SPK-connie: This is still being hashed out a bit, but we believe there will be a couple of "flavors" of the binary toolkit, one of which would include the page compilation and session tracking. Pricing for the various components is still being discussed.
jjustus: What kinds of collections were used in developing
JavaServer? Did you mostly use native arrays for speed reasons, or did you end up using Vectors and JGL constructs for their additional functionality? Is this an optimization that developers should even be considering?
SPK-kluge: All collections that are on the critical path are either arrays, or our own version of the Hashtable class. I removed all uses of the Vector class and the java.util.Hashtable class. The problem with a lot of these collection classes is that they wrap every object in a wrapper object to make a linked list or some such thing. Due to some issues in the 1.1 VM, the new operation creates a lot of lock contention in applications that are trying to scale. Of course, there's no sorting on the critical path. :-) Also, there's no use of the JGL in the server.
splante: I believe I've heard that the Unix versions of JavaServer can authenticate users against the system user list. Is this planned for the NT version?
SPK-connie: Support for NT user lists is in the 1.0 version of the Java Web Server.
SPK-kluge: Has anyone been using the RedirectLoadBalServlet for load balancing? Any feedback on it?
zoltar: Any enhancements to make development easier (i.e. servlets changing, reloading, etc.)?
SPK-connie: We do have plans to provide development tools for servlets, but we do already have automatic reloading of local servlets in our Java Web Server 1.0 product.
splante: Do you mean that in the JS 1.0, we can authenticate users based on their NT userid and password? Without entering them as users in Java Web Server?
SPK-connie: Yes, we have support for NT userid and password, and you don't need to enter them in the Java Web Server.
zoltar: One last thing—how does JavaServer unload and reload classes? Everything I've read about the VM says this isn't really possible (at least not easy).
SPK-kluge: How do you debug your servlets?
zoltar: I did end up moving my classes to the servlets directory. I prefer to use a single "launcher" servlet that calls classes in other packages depending on fields on the HTML form. When one of these other classes changes, it is not always reliably reloaded. I usually debug them using "log" message to the event_log.
sboyle: Where do I get the Server Toolkit binaries?
SPK-connie: The Server Toolkit binary is coming soon. It's not yet available for download.
JoeSam: Have there been discussions with the JDK team regarding the performance concerns you discovered, and possible application to JDK classes? Performance is always a "to the metal" issue, but we would prefer not to have to be leery of poor performance in Java classes. Short of checking the source—poor OO technique—is there any plan for documenting when and where such issues arise?
SPK-kluge: Yes, we are actively working with the JDK team to improve scalability in the 1.2 release. I have created a prototype server that removed all the dirty hacks I did to work around JDK problems. The JDK team is analyzing this server using our benchmarks, and they will improve the VM/core classes based on these observations. HotSpot will also be tuned with the server. There's no official plan to externally document these performance issues. Many of the problems have been logged in Sun's bug tracking database, which I think supported customers have access to. With regard to loading classes—the JavaServer subclasses ClassLoader and creates its own class loaders. These class loaders might, for example, know how to load a class on the local disk but not in CLASSPATH. Some other part of the system would know when that class (i.e. the file) has been modified by checking it at some interval. The file can then be reread, and loaded. A new instance of the server's class loader must be created to do this—class loaders won't load the same class twice. ClassLoader.defineClass() returns an instance of Class, from which a new servlet is created. This new instance atomically replaces the old instance of the servlet in the servlet dispatch mechanism.
MDR-lisa: Thanks, everyone, for making this a great forum. Particular thanks go to Connie and Kevin. Don't forget to sign off, so we can process the transcript quickly and put it on the site by the end of the week. Check our Discussion Forum page to find the transcripts.
