[5.0] Three proposals
Here are some new proposals. 1) Optimization of the session implementation. The session is not a thread safe object. In Tomcat, the session implementation is partially thread safe for some reason (this has been like that since Tomcat 4.0, AFAIK). As a result, we can remove some synchronization. The code should also be simplified (fewer HashMap lookups - ex: remove will return the removed object if there was one, so removeAttribute should be a lot simpler), and avoid event object allocations when it is not useful. As a result of this, setAttribute will become much faster. In addition to this, I will experiment with fixing bug 26051, and will need to add a new endAccess method to the Session interface to do this. All this are rather high risk changes, and should not be ported to 4.1.x. 2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from me :-( I plan to use the '#' character instead, which is not useable in a URI. 3) New connector shutdown. There is a problem with the current Tomcat shutdown order. It works like this: - shutdown the connector - shutdown the webapps (which includes waiting for servlet exec to end, which doesn't make much sense since the connector and its sockets are all gone) This causes trouble in clustering scenarios, where requests which are currently being process will fail in a non predictible fashion. Shutting down in reverse order will not fix problems, as the connector will continue accepting requests (this would help a little, however). So I propose using the following shutdown routine: - notify the connector to stop accepting new requests (we can call this "pausing" the connector) - shutdown the webapps - shutdown the connector This will give requests which were being processed time to complete, and new requests will no longer be accepted. In addition, capability to pause / resume the connector will be added (new JMX operations), which will be useful for cluster node maintenance. For example, to cleanly take down a node: pause the connector, wait for the requests to complete (and session data to replicate), then do the needed maintenance, and finally either unpause the connector or restart the server. Comments ? I will do this after the next stable 5.0.x release (hopefully it will be 5.0.18 :) ), except 1) (where it's centered on one source file, mostly, so it'll be easy to tag the right revision). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
Remy Maucherat wrote: Here are some new proposals. 1) Optimization of the session implementation. The session is not a thread safe object. In Tomcat, the session implementation is partially thread safe for some reason (this has been like that since Tomcat 4.0, AFAIK). As a result, we can remove some synchronization. The code should also be simplified (fewer HashMap lookups - ex: remove will return the removed object if there was one, so removeAttribute should be a lot simpler), and avoid event object allocations when it is not useful. As a result of this, setAttribute will become much faster. In addition to this, I will experiment with fixing bug 26051, and will need to add a new endAccess method to the Session interface to do this. All this are rather high risk changes, and should not be ported to 4.1.x. Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their "SunONE is better performed / more scalable than Apache 2 + Tomcat" benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
Remy Maucherat a écrit : Here are some new proposals. 1) Optimization of the session implementation. The session is not a thread safe object. In Tomcat, the session implementation is partially thread safe for some reason (this has been like that since Tomcat 4.0, AFAIK). As a result, we can remove some synchronization. The code should also be simplified (fewer HashMap lookups - ex: remove will return the removed object if there was one, so removeAttribute should be a lot simpler), and avoid event object allocations when it is not useful. As a result of this, setAttribute will become much faster. In addition to this, I will experiment with fixing bug 26051, and will need to add a new endAccess method to the Session interface to do this. All this are rather high risk changes, and should not be ported to 4.1.x. 2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from me :-( I plan to use the '#' character instead, which is not useable in a URI. 3) New connector shutdown. There is a problem with the current Tomcat shutdown order. It works like this: - shutdown the connector - shutdown the webapps (which includes waiting for servlet exec to end, which doesn't make much sense since the connector and its sockets are all gone) This causes trouble in clustering scenarios, where requests which are currently being process will fail in a non predictible fashion. Shutting down in reverse order will not fix problems, as the connector will continue accepting requests (this would help a little, however). So I propose using the following shutdown routine: - notify the connector to stop accepting new requests (we can call this "pausing" the connector) - shutdown the webapps - shutdown the connector This will give requests which were being processed time to complete, and new requests will no longer be accepted. In addition, capability to pause / resume the connector will be added (new JMX operations), which will be useful for cluster node maintenance. For example, to cleanly take down a node: pause the connector, wait for the requests to complete (and session data to replicate), then do the needed maintenance, and finally either unpause the connector or restart the server. Comments ? I will do this after the next stable 5.0.x release (hopefully it will be 5.0.18 :) ), except 1) (where it's centered on one source file, mostly, so it'll be easy to tag the right revision). I'm not sure if it should happen in TC 5.0.x or 5.1.x but I'd like to investigate in multicast magic for topology determination. If javagroups had been ASF compatible, I could have some code for that, but seems we should do it by hand or via an ASF compatible license tool. The goal is of course in Cluster Group configurations, so each member could know others members (webapp, config). And this in conjunction may be with JK/JK2 successor. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
> I'm not sure if it should happen in TC 5.0.x or 5.1.x but I'd like to > investigate in multicast magic for topology determination. > > If javagroups had been ASF compatible, I could have some code for that, > but seems we should do it by hand or via an ASF compatible license tool. > > The goal is of course in Cluster Group configurations, so each member > could know others members (webapp, config). And this in conjunction > may be with JK/JK2 successor. why not just expand on the existing cluster implementation? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
Jess Holle wrote: Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their "SunONE is better performed / more scalable than Apache 2 + Tomcat" benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. Good for them. However, I'd like to point out that mod_jk 2 is not the best for throughtput. The HTTP connector is. Performance wise, it can't really improve anymore, but I'll try to optimize memory usage to get more scalability (I think it's good enough right now, though). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
As usual, these types of comparisons aren't really useful or even desirable. I remember there used to be a benchmark JSR, but it was with drawn. one of these days, a standard set of web and ejb benchmark apps should be created. that way, instead of the usual simple jsp tests, the performance measurements would be more indicative of how a webapp might perform. from my own experience with coyote connector, it is equal to SunOne, orion, resin, and weblogic. this is based on real applications benchmarked on several servlet containers. Compared to Tomcat 3.2 and older, TC5 has made great strides and remy has worked his butt off. I won't bother pointing out flaws in other servlet containers, since it leads to flame wars. you can google for that information yourself. peter lin Remy Maucherat <[EMAIL PROTECTED]> wrote: Jess Holle wrote: > Any and all performance improvements would be greatly appreciated. > > For those who have not seen it, Sun is touting their "SunONE is better > performed / more scalable than Apache 2 + Tomcat" benchmark. While > Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit > as well as every other web server / servlet engine alternative and > benchmarks are often full of lies, I think it is in everyone's best > interest to keep an eye out for opportunities to ensure Tomcat 5 remains > competetive in terms of performance and scalability. Good for them. However, I'd like to point out that mod_jk 2 is not the best for throughtput. The HTTP connector is. Performance wise, it can't really improve anymore, but I'll try to optimize memory usage to get more scalability (I think it's good enough right now, though). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
Re: [5.0] Three proposals
Remy Maucherat wrote: Jess Holle wrote: Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their "SunONE is better performed / more scalable than Apache 2 + Tomcat" benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. Good for them. However, I'd like to point out that mod_jk 2 is not the best for throughtput. The HTTP connector is. Performance wise, it can't really improve anymore, but I'll try to optimize memory usage to get more scalability (I think it's good enough right now, though). I realize that the extra inter-process hop and marshalling incurred by mod_jk[2] are bound to cause some reduction in throughput. I was actually more concerned by the (lower) scalability plateaus they are showing for Tomcat than the performance per se. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
In general, I agree that general benchmarks are useless and can be slanted towards any alternative you choose. Also I agree that Tomcat generally seems to perform quite well and reliably. -- Jess Holle Peter Lin wrote: As usual, these types of comparisons aren't really useful or even desirable. I remember there used to be a benchmark JSR, but it was with drawn. one of these days, a standard set of web and ejb benchmark apps should be created. that way, instead of the usual simple jsp tests, the performance measurements would be more indicative of how a webapp might perform. from my own experience with coyote connector, it is equal to SunOne, orion, resin, and weblogic. this is based on real applications benchmarked on several servlet containers. Compared to Tomcat 3.2 and older, TC5 has made great strides and remy has worked his butt off. I won't bother pointing out flaws in other servlet containers, since it leads to flame wars. you can google for that information yourself. peter lin Remy Maucherat <[EMAIL PROTECTED]> wrote: Jess Holle wrote: Any and all performance improvements would be greatly appreciated. For those who have not seen it, Sun is touting their "SunONE is better performed / more scalable than Apache 2 + Tomcat" benchmark. While Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit as well as every other web server / servlet engine alternative and benchmarks are often full of lies, I think it is in everyone's best interest to keep an eye out for opportunities to ensure Tomcat 5 remains competetive in terms of performance and scalability. Good for them. However, I'd like to point out that mod_jk 2 is not the best for throughtput. The HTTP connector is. Performance wise, it can't really improve anymore, but I'll try to optimize memory usage to get more scalability (I think it's good enough right now, though). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
Re: [5.0] Three proposals
Remy Maucherat wrote: Here are some new proposals. 2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from me :-( I plan to use the '#' character instead, which is not useable in a URI. 3) New connector shutdown. There is a problem with the current Tomcat shutdown order. It works like this: - shutdown the connector - shutdown the webapps (which includes waiting for servlet exec to end, which doesn't make much sense since the connector and its sockets are all gone) This causes trouble in clustering scenarios, where requests which are currently being process will fail in a non predictible fashion. Shutting down in reverse order will not fix problems, as the connector will continue accepting requests (this would help a little, however). So I propose using the following shutdown routine: - notify the connector to stop accepting new requests (we can call this "pausing" the connector) - shutdown the webapps - shutdown the connector This will give requests which were being processed time to complete, and new requests will no longer be accepted. In addition, capability to pause / resume the connector will be added (new JMX operations), which will be useful for cluster node maintenance. For example, to cleanly take down a node: pause the connector, wait for the requests to complete (and session data to replicate), then do the needed maintenance, and finally either unpause the connector or restart the server. I will proceed with the implementation of 2 and 3. For 3, it is likely that I will add "pause" and "resume" methods on the Connector and ProtocolHandler. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
