RE: TC evolment
From Costin Manolache Sent: Tuesday, April 06, 2004 7:38 AM To: [EMAIL PROTECTED] Subject: Re: TC evolment That's probably why I tought let's integrate PHP was an April 1 joke :-). You were wrong. I thought that MS-Sun agreement was a April fools joke too :). If Mladen is serious about that - I would love to see a solution, hopefully one that can be reused for other systems as well. I'll do my best :) Again - I don't want to discourage Mladen, but to see if he's aware of the problems and if he has some good solution. Don't worry, I'm very stubborn. You'll have to try much harder to discourage me. I would like to see more on the design and tricks he intends to use, maybe we can all learn some stuff. You guys are be the first to know :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Remy Maucherat wrote: Costin Manolache wrote: If you're worried about risk, then probably glueing PHP with tomcat will be a bad choice. Tomcat is limited by Java's bad support for integration with native code. Apache will have no problem running Php, perl, python, .net or integrating with any native library that exists today. For tomcat running openSSL seems to be a big thing, and we know too well how difficult it is to get it working with JNI. For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) We'll see the result when it's done :) If Mladen wants to try it because he feels like he has a need for it, it's fine by me. And there is the maintainability, scalability, etc. which I think Java is better at. Well I made some benchmarks on TC 3.3.2, TC 4.1.30, TC 5.0.19, Apache 2, mod_php 4.3.5 and mod_php 5.0RC1 this week-end and you could see that to serve the good old HelloWorld (or its html/php counter part), Java is allways faster. This 'bench' has been conducted on a Pentium 4 with 512Mo RAM , Windows XP and Sun SDK 1.4.2-04. I used each time the default server configurations. Regards Tomcat 3.3.2 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /examples/servlet/HelloWorldExample Document Length:419 bytes Concurrency Level: 16 Time taken for tests: 1.902736 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 546000 bytes HTML transferred: 419000 bytes Requests per second:525.56 [#/sec] (mean) Time per request: 30.444 [ms] (mean) Time per request: 1.903 [ms] (mean, across all concurrent requests) Transfer rate: 280.12 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 2.8 0 10 Processing: 0 28 5.1 30 50 Waiting:0 14 9.6 10 40 Total: 0 29 4.7 30 50 Percentage of the requests served within a certain time (ms) 50% 30 66% 30 75% 30 80% 30 90% 30 95% 40 98% 40 99% 40 100% 50 (longest request) --- Tomcat 4.1.30 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /examples/servlet/HelloWorldExample Document Length:411 bytes Concurrency Level: 16 Time taken for tests: 2.143081 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 559000 bytes HTML transferred: 411000 bytes Requests per second:466.62 [#/sec] (mean) Time per request: 34.289 [ms] (mean) Time per request: 2.143 [ms] (mean, across all concurrent requests) Transfer rate: 254.31 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:01 3.0 0 10 Processing:10 32 5.3 30 50 Waiting:0 16 10.7 20 50 Total: 10 33 5.6 30 50 Percentage of the requests served within a certain time (ms) 50% 30 66% 40 75% 40 80% 40 90% 40 95% 40 98% 40 99% 50 100% 50 (longest request) --- Tomcat 5.0.19 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /servlets-examples/servlet/HelloWorldExample Document Length:365 bytes Concurrency Level: 16 Time taken for tests: 2.173125 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 513000 bytes HTML transferred: 365000 bytes Requests per second:460.17 [#/sec] (mean) Time per request: 34.770 [ms] (mean) Time per request: 2.173 [ms] (mean, across all concurrent requests) Transfer rate: 230.08 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 3.1 0 20 Processing: 0 33 6.1 30 60 Waiting:0 16 10.7 20 50 Total: 0 34 6.5 30 60 Percentage of the requests served within a certain time (ms) 50% 30 66% 40 75% 40 80% 40 90% 40 95% 40 98% 50 99% 60 100% 60 (longest request) --- Apache 2.0.49 (Windows) Server Software:Apache/2.0.49 Server Hostname:127.0.0.1 Server Port:80 Document Path: /helloworld.html Document Length:365 bytes
Re: TC evolment
Henri Gomez wrote: Remy Maucherat wrote: Costin Manolache wrote: If you're worried about risk, then probably glueing PHP with tomcat will be a bad choice. Tomcat is limited by Java's bad support for integration with native code. Apache will have no problem running Php, perl, python, .net or integrating with any native library that exists today. For tomcat running openSSL seems to be a big thing, and we know too well how difficult it is to get it working with JNI. For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) We'll see the result when it's done :) If Mladen wants to try it because he feels like he has a need for it, it's fine by me. And there is the maintainability, scalability, etc. which I think Java is better at. Well I made some benchmarks on TC 3.3.2, TC 4.1.30, TC 5.0.19, Apache 2, mod_php 4.3.5 and mod_php 5.0RC1 this week-end and you could see that to serve the good old HelloWorld (or its html/php counter part), Java is allways faster. This 'bench' has been conducted on a Pentium 4 with 512Mo RAM , Windows XP and Sun SDK 1.4.2-04. I used each time the default server configurations. Well, we know this from quite some time ( I think IBM JDK1.3.1 was the first to allow tomcat3.3 hello world to run faster than apache ). If you do the right things - you can make java code faster or as fast as C code. We also know that IIS or iPlanet may sometimes be faster than apache or tomcat. So what ? As we used to say on tomcat-dev when we were slower than apache - performance is not the only thing that matters. I would bet resin is still a bit faster ( probably not much now :-), and you could probably find other servlet engines that may still be faster than tomcat. I don't think people use PHP because it's faster than perl or python, or they used apache because it was faster. Success can be dangerous sometimes - it's important to keep things in perspective :-) Costin Regards Tomcat 3.3.2 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /examples/servlet/HelloWorldExample Document Length:419 bytes Concurrency Level: 16 Time taken for tests: 1.902736 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 546000 bytes HTML transferred: 419000 bytes Requests per second:525.56 [#/sec] (mean) Time per request: 30.444 [ms] (mean) Time per request: 1.903 [ms] (mean, across all concurrent requests) Transfer rate: 280.12 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 2.8 0 10 Processing: 0 28 5.1 30 50 Waiting:0 14 9.6 10 40 Total: 0 29 4.7 30 50 Percentage of the requests served within a certain time (ms) 50% 30 66% 30 75% 30 80% 30 90% 30 95% 40 98% 40 99% 40 100% 50 (longest request) --- Tomcat 4.1.30 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /examples/servlet/HelloWorldExample Document Length:411 bytes Concurrency Level: 16 Time taken for tests: 2.143081 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 559000 bytes HTML transferred: 411000 bytes Requests per second:466.62 [#/sec] (mean) Time per request: 34.289 [ms] (mean) Time per request: 2.143 [ms] (mean, across all concurrent requests) Transfer rate: 254.31 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:01 3.0 0 10 Processing:10 32 5.3 30 50 Waiting:0 16 10.7 20 50 Total: 10 33 5.6 30 50 Percentage of the requests served within a certain time (ms) 50% 30 66% 40 75% 40 80% 40 90% 40 95% 40 98% 40 99% 50 100% 50 (longest request) --- Tomcat 5.0.19 / Coyote HTTP 1.1 Server Software:Apache-Coyote/1.1 Server Hostname:127.0.0.1 Server Port:8080 Document Path: /servlets-examples/servlet/HelloWorldExample Document Length:365 bytes Concurrency Level: 16 Time taken for tests: 2.173125 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 513000 bytes HTML transferred:
Re: TC evolment
Shapira, Yoav wrote: Hi, Fact is Java ( or at least the current JVMs) is among the worse languages when it comes to integration with other systems. Connectors are attempts to solve this. Whoa there ;) Maybe if you're talking about JNI, but not integration in general ;) It's a very broad term. Integration with other native, complex systems - not only via JNI - is usually a big pain. Some browsers ( konqueror for example ) don't even use JNI ( AFAIK ) for their applets - but a sort of out-of-process connector. Same for mozilla ( or at least some variants ). I think it's important to recognize the problems and try to solve them - this is IMO one of the weak points in java ( and one of the few areas where .net is significantly better ). That's probably why I tought let's integrate PHP was an April 1 joke :-). If Mladen is serious about that - I would love to see a solution, hopefully one that can be reused for other systems as well. Long ago, mod_jk had as a goal to integrate with apache ( auth, etc ). I think fully integrating PHP ( in the sense of bi-directional communication - php pages using java components and java using php fragments / modules ) is much harder. Again - I don't want to discourage Mladen, but to see if he's aware of the problems and if he has some good solution. I would like to see more on the design and tricks he intends to use, maybe we can all learn some stuff. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
From Costin Manolache We also know that IIS or iPlanet may sometimes be faster than apache or tomcat. So what ? As we used to say on tomcat-dev when we were slower than apache - performance is not the only thing that matters. I would bet resin is still a bit faster ( probably not much now :-), and you could probably find other servlet engines that may still be faster than tomcat. He he :) If the performance is not the only thing that matters, then I'm on the right track. Think you said something different couple of mails before, but I'm glad to see things have changed :). I don't think people use PHP because it's faster than perl or python, or they used apache because it was faster. Success can be dangerous sometimes - it's important to keep things in perspective :-) It all depends what your perspective is. I'm trying to redefine mine as a Tomcat being a master http server, so I'm trying to provide it with the things that this kind of application should have, and one of them is a better native integration. Of course when you put 1.6 billion $ on the table the perspective can be changed in various directions :) MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Costin Manolache wrote: If you're worried about risk, then probably glueing PHP with tomcat will be a bad choice. Tomcat is limited by Java's bad support for integration with native code. Apache will have no problem running Php, perl, python, .net or integrating with any native library that exists today. For tomcat running openSSL seems to be a big thing, and we know too well how difficult it is to get it working with JNI. For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) We'll see the result when it's done :) If Mladen wants to try it because he feels like he has a need for it, it's fine by me. And there is the maintainability, scalability, etc. which I think Java is better at. Java may be more maintainable - but in this particular case do you think PHP + JNI/connector + tomcat would be more maintainable than the existing and well tested Apache + mod_php ? Well, it doesn't seem that PHP + Apache 2 is that well tested either ;) In the end, the JSR from Zend and others shows this may not be a bad direction. Obviously, mod_jk and similar technologies need to exist for integration purposes, or any setup where Java isn't the main technology used. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: Remy Maucherat For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) We'll see the result when it's done :) If Mladen wants to try it because he feels like he has a need for it, it's fine by me. Basically I'd like to do two things for start: a) Servlet 2.4 native interface, that will load native libraries like a standard servlet. b) PHP sapi (in additon of few simpler ones) as an example for consuming such a interface. Well, it doesn't seem that PHP + Apache 2 is that well tested either ;) In the end, the JSR from Zend and others shows this may not be a bad direction. Obviously, mod_jk and similar technologies need to exist for integration purposes, or any setup where Java isn't the main technology used. Yes, the JSR 223 (although haven't found a final spec. jet) itself is talking about native integration, and IMHO it makes sence for particular use cases. OTOH connector architecture has a different perspective, and it is meant to be used in different situations like you said. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: Remy Maucherat For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) We'll see the result when it's done :) If Mladen wants to try it because he feels like he has a need for it, it's fine by me. I'm not trying to stop him. I am also very interested in Java-native communication. However I haven't seen too many success stories of good integration of native language and java ( even in the cases where it-kind-of-works, it is still hacky and few people use it for real stuff ). So if what he needs is PHP - I think it's fair to suggest using Apache for that :-) Basically I'd like to do two things for start: a) Servlet 2.4 native interface, that will load native libraries like a standard servlet. b) PHP sapi (in additon of few simpler ones) as an example for consuming such a interface. Well, for start - how do you plan to do the native interface ? I assume JNI, but which flavor ? SWT-style ( only int and array parameters, tiny native methods ) or jk2 style ( marshalling - even if in process ) ? Did you find any other way to get decent speed out of JNI? Well, it doesn't seem that PHP + Apache 2 is that well tested either ;) In the end, the JSR from Zend and others shows this may not be a bad direction. Obviously, mod_jk and similar technologies need to exist for integration purposes, or any setup where Java isn't the main technology used. Yes, the JSR 223 (although haven't found a final spec. jet) itself is talking about native integration, and IMHO it makes sence for particular use cases. OTOH connector architecture has a different perspective, and it is meant to be used in different situations like you said. ) I'm not sure we are talking about the same thing here - by connector I mean something similar with XPConnect or UNO. Jk is a very specialized case ( actually a mix between a http request forwarder and a minimal marshalling-based connector ). The role of the connector is to make the adaptation between the runtimes used on the 2 sides and deal with the limitations of JNI. Fact is Java ( or at least the current JVMs) is among the worse languages when it comes to integration with other systems. Connectors are attempts to solve this. Having a JSR for native integration doesn't change the problem - applets have been a standard part of Java since 1.0, and they still don't work very well (except maybe on windows ). And applets are a much simpler problem than integrating 2 languages. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: Andy Armstrong Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. What do you mean by 'integrate'? Have tomcat handle PHP requests by some means? mod_php inside TC. I found out that TC is only 8% slower the Apache2.x. So if I need PHP and JSP, the Apache2 is total overhead. MT. I hope this is an April 1 joke :-) Maybe you can also integrate mod_perl and mod_dotnet ( or whatever is called ) :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
From Costin Manolache mod_php inside TC. I found out that TC is only 8% slower the Apache2.x. So if I need PHP and JSP, the Apache2 is total overhead. MT. I hope this is an April 1 joke :-) Maybe you can also integrate mod_perl and mod_dotnet ( or whatever is called ) :-) Someone told me back in '80 that he's going to install the 1MB of RAM to some mainframe. I thought it was a April 1 joke then, cause I couldn't figure out why would someone need that :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. The webserver is not only for static content. If you use Apache just because it serves the static content faster than tomcat - you are using it for the wrong reason. A lot of people use Apache because they feel it's more stable and secure. Other use it because of the hundreds of modules - like mod_php, mod_perl, etc. Yes, you could make mod_php work with tomcat - or you could even rewrite the entire php in java. And nobody can stop you from doing this if you have the time and itch. But if you just want to use PHP instead of JSP - you may be better just doing it with the existing stable solution, which is Apache. The raw page speed is not everything. There is also the memory use, CPU load, startup time, stability, etc. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
From Costin Manolache Sent: Saturday, April 03, 2004 9:14 AM If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? The webserver is not only for static content. If you use Apache just because it serves the static content faster than tomcat - you are using it for the wrong reason. Yes, but I found myself lately to use it just for glueing those techologies together, of course thanks to the large module database, it's not such a big deal. Having every content passing several systems is not so stable solution thought, cause each channel will add it's risk percentage. The raw page speed is not everything. There is also the memory use, CPU load, startup time, stability, etc. And there is the maintainability, scalability, etc. which I think Java is better at. As you said nothing stops me of doing something like that, and of course nothing stops me being totally wrong :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: From Costin Manolache Sent: Saturday, April 03, 2004 9:14 AM If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? The webserver is not only for static content. If you use Apache just because it serves the static content faster than tomcat - you are using it for the wrong reason. Yes, but I found myself lately to use it just for glueing those techologies together, of course thanks to the large module database, it's not such a big deal. Having every content passing several systems is not so stable solution thought, cause each channel will add it's risk percentage. If you're worried about risk, then probably glueing PHP with tomcat will be a bad choice. Tomcat is limited by Java's bad support for integration with native code. Apache will have no problem running Php, perl, python, .net or integrating with any native library that exists today. For tomcat running openSSL seems to be a big thing, and we know too well how difficult it is to get it working with JNI. For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) The raw page speed is not everything. There is also the memory use, CPU load, startup time, stability, etc. And there is the maintainability, scalability, etc. which I think Java is better at. Java may be more maintainable - but in this particular case do you think PHP + JNI/connector + tomcat would be more maintainable than the existing and well tested Apache + mod_php ? About scalability - April 1 is over on my timezone :-) As you said nothing stops me of doing something like that, and of course nothing stops me being totally wrong :). Well, what would be wrong is to not try if you think it's a good idea:-) I'm allways interested in integration between Java and native code - and even if I don't think Tomcat+PHP would stand a chance to Apache+mod_php - I'm looking forward to see more work in the area of JNI or connectivity between java and the rest of the world. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: Henri Gomez I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? Yes something like that, It will allow mod_jk2 lb features and header preproc, but in pure Java, and it'll need to expose some kind of the API, usable from native code. Having that in Java will allow dynamic config either using JMX or some other technology. Will it use ajp13 as a messaging protocol? I don't know yet. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: Henri Gomez I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? Yes something like that, It will allow mod_jk2 lb features and header preproc, but in pure Java, and it'll need to expose some kind of the API, usable from native code. Having that in Java will allow dynamic config either using JMX or some other technology. Will it use ajp13 as a messaging protocol? I don't know yet. The discussion is open :) In fact we could need only a TC5 subset, mainly only Coyote HTTP 1.1. To forward request to remote Tomcat we could use AJP or may be RMI ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Remy Maucherat wrote: Mladen Turk wrote: mod_php inside TC. How does that work ? I found out that TC is only 8% slower the Apache2.x. 8% for doing what ? (this will heavily depend on the VM you're using, anyway, so try JRockit to get the good results :) ) 8% slower to serve only static pages ? Which JVM and OS ? So if I need PHP and JSP, the Apache2 is total overhead. You mean: JSP through Apache is slower, so you think a little more overhead on PHP would make for a better average ? I'm not quite convinced yet ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Henri Gomez wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. +0 wistful-smile And to think it was only a couple of years ago that I got thorougly chastised (by more than a few people participating in this thread :-) for suggesting that Tomcat standalone might actually be a viable production solution for some applications. /wistful-smile The recent improvements in the perfornance of Tomcat standalone (with refactorings like the Coyote connector, plus other optimizations in the Catalina core) have definitely widened the scope of applications where Tomcat standalone is good enough ... but it always has been for any departmental app with a limited user population (which is a many-orders-of-magnitude number of real live apps). I'm glad to see that the Tomcat isn't worthy of standalone status, it needs to be hidden behind a *real* web server crowd are finally coming to understand that there is a substantial number of use cases where Tomcat standalone is a perfectly reasonable solution. Or, if you'd prefer it in a sound bite ... fast enough is fast enough. If Tomcat standalone meets your performance requirements, you have my blessing if you choose to avoid the pain of learning how to configure it to integrate with Apache's HTTPD server :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Thanks Craig (Was: Re: TC evolment)
--- Craig McClanahan [EMAIL PROTECTED] wrote: wistful-smile And to think it was only a couple of years ago that I got thorougly chastised (by more than a few people participating in this thread :-) for suggesting that Tomcat standalone might actually be a viable production solution for some applications. /wistful-smile If it makes you feel good: I was a lurker on those old threads. I'm happy to say that I decided to go along with your judgement and use Tomcat for some solutions that we'd need to deliver. I'd used TC 4.0.1 way back then, and our apps are still running fine on the following configuration :Win98, Pentium 200MMX, 64 MB RAM, JDK 1.3.1. Craig McClanahan -- Sriram __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: Henri Gomez I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? Yes something like that, It will allow mod_jk2 lb features and header preproc, but in pure Java, and it'll need to expose some kind of the API, usable from native code. Having that in Java will allow dynamic config either using JMX or some other technology. Will it use ajp13 as a messaging protocol? I don't know yet. MT. Hi All, Just thought I'd chip in! Please feel free to ignore me. I use tomcat exclusively behind apache. This is for performance reasons both as a proxy for slow clients (releasing relatively expensive tomcat resources) and as a static content server. We use apache to control our URL space and serve all sorts of content from all sorts of servers. In many instances tomcat, or jboss or any other app server does not have the control over the URL/Request that apache gives us without allot of custom coding. We use mod_rewrite, mod_proxy, php, mod_perl, mod_some_auth_module. I have not benchmarked it but I would be surprised it tomcat was as good as apache in an SSL environment. Just my 2 pence worth, to defend us flat earth people that still use Apache (mostly 1.3.x as well) in front of tomcat for lots of quite sensible reasons. I do agree that a lot of tomcats are stand alone and that these can be quite usefully setup without apache is a valid one, but not an exclusively so. Greg ps I still see an 80/20 rule of 80% static content, 20% dynamic both in traffic and war file content. Not to say the 20% does not involve a lot of processing to produce! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: [EMAIL PROTECTED] I use tomcat exclusively behind apache. This is for performance reasons both as a proxy for slow clients (releasing relatively expensive tomcat resources) and as a static content server. As said, it all depends on a particular use case. If the majority of your content is static, then Apache2 will probably scale better, but IMHO, those cases will tend to decrease, cause the Moore law is proven to be correct, so that prices for the processing resources are decreasing too. For any portal or similar type of web content delivery, the time spent on processing 'standard' http protocol tasks including the TCP/IP stack is insignificant compared to the time spent in the application itself. We use apache to control our URL space and serve all sorts of content from all sorts of servers. In many instances tomcat, or jboss or any other app server does not have the control over the URL/Request that apache gives us without allot of custom coding. We use mod_rewrite, mod_proxy, php, mod_perl, mod_some_auth_module. Well, those kind of functionally are the one I wish to provide to the Tomcat. Again, the major advantage for a webserver in front of Tomcat nowadays is that this is probably the only way to intermix Java, PHP and Perl. If we have a direct support for the later two, then the advantage would become a bottleneck thought. ps I still see an 80/20 rule of 80% static content, 20% dynamic both in traffic and war file content. Not to say the 20% does not involve a lot of processing to produce! Even on a 80-20 scenario (the better measure would be CPU times), the TC alone would IMO give you performace increase, but the best way to test that is a plain old 'ab' :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
On Thu, Apr 01, 2004 at 12:04:35PM +0100, [EMAIL PROTECTED] wrote: -Original Message- From: Henri Gomez I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? Yes something like that, It will allow mod_jk2 lb features and header preproc, but in pure Java, and it'll need to expose some kind of the API, usable from native code. Having that in Java will allow dynamic config either using JMX or some other technology. Will it use ajp13 as a messaging protocol? I don't know yet. MT. Hi All, Just thought I'd chip in! Please feel free to ignore me. I use tomcat exclusively behind apache. This is for performance reasons both as a proxy for slow clients (releasing relatively expensive tomcat resources) and as a static content server. We use apache to control our URL space and serve all sorts of content from all sorts of servers. In many instances tomcat, or jboss or any other app server does not have the control over the URL/Request that apache gives us without allot of custom coding. We use mod_rewrite, mod_proxy, php, mod_perl, mod_some_auth_module. I have not benchmarked it but I would be surprised it tomcat was as good as apache in an SSL environment. Just my 2 pence worth, to defend us flat earth people that still use Apache (mostly 1.3.x as well) in front of tomcat for lots of quite sensible reasons. I do agree that a lot of tomcats are stand alone and that these can be quite usefully setup without apache is a valid one, but not an exclusively so. Greg ps I still see an 80/20 rule of 80% static content, 20% dynamic both in traffic and war file content. Not to say the 20% does not involve a lot of processing to produce! I couldn't have said it any better. As an example. I run a SOAP server with Tomcat Standalone which uses HTTPS for the transport. I recently switched to PureTLS using a JNI plugin so that OpenSSL libs were used instead of java byte code for SSL. The boost in performance was amazing. 10x faster. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. What do you mean by 'integrate'? Have tomcat handle PHP requests by some means? -- Andy Armstrong, Tagish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
Hi, I once looked at writing a PHP Servlet. I know the CGI and JSP servlets fairly well, and it seemed not too terrible a task. But after reading the PHP spec, I realized it was a serious effort if I wanted to implement a meaningful subset of the PHP spec. So I backed off and pursued other projects (unrelated, in the OpenJMS space). Do I think it'd be useful? Definitely. I always see and hear people clamoring over the ease of development PHP brings to the table. So the ability to combine PHP with everything else tomcat offers would really add flexibility and power to tomcat. I think users would like it and I don't think our competitors offer something like this. Yoav Shapira Millennium Research Informatics -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 11:31 AM To: Tomcat Developers List Subject: TC evolment Hi, Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. Are there any thoughts on the subject, or perhaps someone is already working on it? Anyhow I'd like to hear are there any pros or cons, and finally are there any interest of doing that at all. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: Andy Armstrong Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. What do you mean by 'integrate'? Have tomcat handle PHP requests by some means? mod_php inside TC. I found out that TC is only 8% slower the Apache2.x. So if I need PHP and JSP, the Apache2 is total overhead. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: Andy Armstrong Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. What do you mean by 'integrate'? Have tomcat handle PHP requests by some means? mod_php inside TC. I found out that TC is only 8% slower the Apache2.x. So if I need PHP and JSP, the Apache2 is total overhead. So at last year's JavaOne conference, it was mentioned that Tomcat was going to support PHP. I thought that odd, since this community itself wasn't talking about it necessarily. I think what it really was getting to was JSR 223, which deals with interoperability between scripting languages (PHP being the first candidate) and Java. I do not know what is happening with JSR 223... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: mod_php inside TC. How does that work ? I found out that TC is only 8% slower the Apache2.x. 8% for doing what ? (this will heavily depend on the VM you're using, anyway, so try JRockit to get the good results :) ) So if I need PHP and JSP, the Apache2 is total overhead. You mean: JSP through Apache is slower, so you think a little more overhead on PHP would make for a better average ? I'm not quite convinced yet ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
Hi, So if I need PHP and JSP, the Apache2 is total overhead. You mean: JSP through Apache is slower, so you think a little more overhead on PHP would make for a better average ? I read that to say: if I need PHP and JSP, but not other Apache features, then being able to use tomcat standalone would be great. And I agree ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: Hi, Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). Are there any thoughts on the subject, or perhaps someone is already working on it? Anyhow I'd like to hear are there any pros or cons, and finally are there any interest of doing that at all. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
-Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
Hi, I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. I agree, have done so myself a while ago, and have encouraged others to do it for at least a couple of years. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Ok. If you manage to do it, I think performance is going to be important, and you (= we)'ll need to publicize it. It has to be comparable to Apache 2 / mod_php, obviously ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. +0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Henri Gomez wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. Interesting idea Mladen. +0 Next idea. If we drop Apache 2.0 support we need to have jk/jk2 jobs done somewhere : What about Tomcat 5 Coyote as a ajp13 dispatcher with advances and fine tuning rules, which could be updated in real time in via JMX ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
