RE: TC evolment

2004-04-06 Thread Mladen Turk
 

 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

2004-04-05 Thread Henri Gomez
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

2004-04-05 Thread Costin Manolache
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

2004-04-05 Thread Costin Manolache
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

2004-04-05 Thread Mladen Turk
 

 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

2004-04-03 Thread Remy Maucherat
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

2004-04-03 Thread Mladen Turk
 

 -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

2004-04-03 Thread Costin Manolache
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

2004-04-02 Thread Costin Manolache
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

2004-04-02 Thread Mladen Turk
 

 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

2004-04-02 Thread Costin Manolache
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

2004-04-02 Thread Mladen Turk
 

 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

2004-04-02 Thread Costin Manolache
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

2004-04-01 Thread Mladen Turk
 

 -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

2004-04-01 Thread Henri Gomez
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

2004-04-01 Thread Henri Gomez
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

2004-04-01 Thread Craig McClanahan
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)

2004-04-01 Thread Sriram N

--- 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

2004-04-01 Thread Greg . Cope
  -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

2004-04-01 Thread Mladen Turk
 

 -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

2004-04-01 Thread Glenn Nielsen
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]



TC evolment

2004-03-31 Thread Mladen Turk
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]



Re: TC evolment

2004-03-31 Thread Andy Armstrong
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

2004-03-31 Thread Shapira, Yoav

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

2004-03-31 Thread Mladen Turk
 

 -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

2004-03-31 Thread Jeff Tulley
 -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

2004-03-31 Thread Remy Maucherat
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

2004-03-31 Thread Shapira, Yoav

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

2004-03-31 Thread jean-frederic clere
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

2004-03-31 Thread Mladen Turk
 

 -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

2004-03-31 Thread Shapira, Yoav

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

2004-03-31 Thread Remy Maucherat
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

2004-03-31 Thread Henri Gomez
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

2004-03-31 Thread Henri Gomez
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]