Re: Different webapp paths on different hosts
On 1/28/2013 7:13 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
bxqdev,
On 1/26/13 1:09 AM, bxqdev wrote:
On 1/26/2013 1:05 AM, Christopher Schultz wrote: Dude,
On 1/25/13 12:38 AM, bxqdev wrote:
i want to have one instance of webapp,
No problem.
which has two paths,
Problem: one context = one path = one instance
If you want two separate paths, you need two separate contexts.
and each of the paths serves the root of different domains
That just doesn't make any sense. The root of a domain is, by
definition, / (contextPath=), so there aren't any other paths
to consider.
looks like the goal is not reachable with plain tomcat
configuration.
once again: * one webapp * has 2 different paths: /path1
and /path2 * served on 2 domains * when user goes to
http://path1.com/ - {webapp}/path1 is served as root path *
when user goes to http://path2.com/ - {webapp}/path2 is
served as root path
is it possible?
What you are saying is nonsensical (specifically, the part where
you say that you want /path1 to be mapped to root.
If you want two virtual hosts, then define two virtual hosts. If
you want an app on each host configured as ROOT, then make your
two virtual hosts have two separate appBase directories (which
should be a requirement in the first place of two virtual hosts)
and toss a copy of your WAR file in each appBase, both named
ROOT.war (cApITaLS matter).
You can't deploy a single copy (in memory) of your webapp and
expect to get all your requirements above met. If you want to have
a single WAR file on the disk and deploy it multiple times, you
*can* do that but I'm not sure why anyone would want to.
looks like the goal is not reachable with plain tomcat
configuration.
I seriously don't understand your goal or your problem. It sounds
like you want two separate webapps smashed into a single context where
one webapp gets served by one domain and another webapps gets served
by the other domain. I don't know why you don't just split them up
into two separate webapps just like $DIETY intended.
if that was the solution, i wouldn't ask the question in the first place.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEGlY0ACgkQ9CaO5/Lv0PD86wCfcid6tNjOzzR0BJZh2tF5672y
09kAmwQ/o+S3jP3Ii033Wfm1UkVmecXs
=shqR
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/28/2013 7:11 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 bxqdev, On 1/26/13 3:04 PM, bxqdev wrote: On 1/26/2013 9:36 PM, Caldarale, Charles R wrote: From: cjder...@gmail.com [mailto:cjder...@gmail.com] On Behalf Of chris derham Subject: Re: Different webapp paths on different hosts To my mind if you deploy the app as ROOT.war, as long as DNS is configured correctly, that single context will serve responses to http://app1.com/ and http://app2.com/. This appears solves the explicit requirement stated above. Which is what I suggested back on 23 January: Assuming path1.com and path2.com evaluate to the same IP address (or at least to the same system), this will happen automatically with a single Host element in the Tomcat configuration. But the OP refuses to supply any information about why that's not sufficient. - Chuck in this case http://app1.com/ and http://app2.com/ will serve the same content. i need different content on different domains. Something actually made a little pop in my brain when I read that. I gotta go... I think I smell toast burning... i take it as you don't know the correct answer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEGlRIACgkQ9CaO5/Lv0PBywQCeO1wxbRMQX6reeKVzCaYCjIY8 F74An104rdsUKFUucCNBZgfBC3Mh+7Lr =d8JI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/26/2013 9:23 PM, chris derham wrote:
it's not. maybe it will make things clear if i change the names of the
paths, say:
* when user goes to http://app1.com/ - {thesamewebapp}/app1 path is served
as root path of the domain app1.com
* when user goes to http://app2.com/ - {thesamewebapp}/app2 path is served
as root path of the domain app2.com
From this I conclude that the explicit requirement is to have a single
running version of the war, that responds to different domains. You
seem to think that you have an additional implicit requirement that
this must be done within tomcat by having different contexts. This
seems to me to be the source of confusion in all the replies to your
thread.
actually it would only be more convenient to do this with just tomcat.
but i would like to know any methods that solve the problem.
What you are trying to do is make the same webapp answer both
domain1.com/ and domain2.com/ right? If so you can simply
deploy the webapp as ROOT. The webapp will then answer on all domains
pointing to the server. If this is not what you want, you
can set up a virtual host in server.xml with an appbase outside the
webapps folder (eg. $CATALINA_BASE (or is it HOME?)$\domain1
and then use the Alias element to specify the second domain as an alias
for the first (which you set as an attribute in the
Host element).
i know these tricks, but they don't work for my case.
To my mind if you deploy the app as ROOT.war, as long as DNS is
configured correctly, that single context will serve responses to
http://app1.com/ and http://app2.com/. This appears solves the
explicit requirement stated above. However you state they don't work
for my case - please explain why this doesn't work for your case
in this case http://app1.com/ and http://app2.com/ will serve the same content.
i need different content on different domains.
Thanks
Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/26/2013 9:36 PM, Caldarale, Charles R wrote: From: cjder...@gmail.com [mailto:cjder...@gmail.com] On Behalf Of chris derham Subject: Re: Different webapp paths on different hosts To my mind if you deploy the app as ROOT.war, as long as DNS is configured correctly, that single context will serve responses to http://app1.com/ and http://app2.com/. This appears solves the explicit requirement stated above. Which is what I suggested back on 23 January: Assuming path1.com and path2.com evaluate to the same IP address (or at least to the same system), this will happen automatically with a single Host element in the Tomcat configuration. But the OP refuses to supply any information about why that's not sufficient. - Chuck in this case http://app1.com/ and http://app2.com/ will serve the same content. i need different content on different domains. THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/25/2013 12:11 PM, Casper Wandahl Schmidt wrote:
See inline
Med venlig hilsen/Kind regards
Casper W. Schmidt
Den 25-01-2013 06:38, bxqdev skrev:
On 1/24/2013 11:52 AM, Casper Wandahl Schmidt wrote:
See inline
Med venlig hilsen/Kind regards
Casper W. Schmidt
Den 24-01-2013 02:32, Christopher Schultz skrev:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
BBQ,
On 1/23/13 12:09 AM, bxqdev wrote:
i need to map a custom paths, like /path1 and /path2, (not root
/ path), of the same webapp to a custom domains.
as i said i need this mapping: ${samewebapp}/path1 is mapped to
http://path1.com/ ${samewebapp}/path2 is mapped to
http://path2.com/
NOT this: ${samewebapp}/path1 is mapped to http://path1.com/path1
${samewebapp}/path2 is mapped to http://path2.com/path2
What is ${samewebpp}/path1? Is that a piece of a webapp?
Do you care if the same webapp is deployed twice (which is probably
going to be required)?
Actually the OP is not really clear in describing anything. I'm wondering if path1 in
http://path1.com equals path1 in the
/path1 part or not.
actually the path names and domain names should be able to be different
Anyway I would say a context.xml file in conf/catalina/path1 (the
hostname)/path1.xml (the context name) should do the trick?
Place the webapp outside the appbase of the hosts and then point the docbase to
the webapp (or just drop the .war with two
different names in the appbases of the two hosts) :)
i want to have one instance of webapp,
which has two paths,
and each of the paths serves the root of different domains
once again:
* one webapp
* has 2 different paths: /path1 and /path2
* served on 2 domains
* when user goes to http://path1.com/ - {webapp}/path1 is served as root path
* when user goes to http://path2.com/ - {webapp}/path2 is served as root path
is it possible?
To me it doesn't make sense to say that the webapp has two different paths,
/path1 and path2, and then say the webapp is to be
served as root from two different hosts. I guess it's simply a case of bad
terminology :)
it's not. maybe it will make things clear if i change the names of the paths,
say:
* when user goes to http://app1.com/ - {thesamewebapp}/app1 path is served as
root path of the domain app1.com
* when user goes to http://app2.com/ - {thesamewebapp}/app2 path is served as
root path of the domain app2.com
Anyway. What you are trying to do is make the same webapp answer both
domain1.com/ and domain2.com/ right? If so you can simply
deploy the webapp as ROOT. The webapp will then answer on all domains pointing
to the server. If this is not what you want, you
can set up a virtual host in server.xml with an appbase outside the webapps
folder (eg. $CATALINA_BASE (or is it HOME?)$\domain1
and then use the Alias element to specify the second domain as an alias for
the first (which you set as an attribute in the
Host element).
i know these tricks, but they don't work for my case.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEAj0cACgkQ9CaO5/Lv0PCChwCggGZi3v8ylGaj6py+uQ2ZNuq9
0+QAnR5ENaqoollzjpB5dx7KtcT3mquu
=/GYF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/25/2013 12:29 PM, Konstantin Kolinko wrote:
2013/1/25 bxqdev bxq...@themailbay.com:
Anyway I would say a context.xml file in conf/catalina/path1 (the
hostname)/path1.xml (the context name) should do the trick?
Place the webapp outside the appbase of the hosts and then point the
docbase to the webapp (or just drop the .war with two
different names in the appbases of the two hosts) :)
i want to have one instance of webapp,
which has two paths,
and each of the paths serves the root of different domains
once again:
* one webapp
* has 2 different paths: /path1 and /path2
* served on 2 domains
* when user goes to http://path1.com/ - {webapp}/path1 is served as root
path
* when user goes to http://path2.com/ - {webapp}/path2 is served as root
path
is it possible?
Two different instances of the same webapp at different hosts - easy.
E.g. the manager webapp is deployed in such way to the virtual hosts.
One instance mapped to different paths - impossible. What value should
be returned by javax.servlet.ServletContext.getContextPath() ?
Thought it is possible to apply urlrewriting, either at HTTPD or at Tomcat.
looks like url rewriting is the only way. though i was wondering if it's
possible to do the trick with tomcat configuration.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/26/2013 1:05 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dude,
On 1/25/13 12:38 AM, bxqdev wrote:
i want to have one instance of webapp,
No problem.
which has two paths,
Problem: one context = one path = one instance
If you want two separate paths, you need two separate contexts.
and each of the paths serves the root of different domains
That just doesn't make any sense. The root of a domain is, by
definition, / (contextPath=), so there aren't any other paths to
consider.
looks like the goal is not reachable with plain tomcat configuration.
once again: * one webapp * has 2 different paths: /path1 and
/path2 * served on 2 domains * when user goes to
http://path1.com/ - {webapp}/path1 is served as root path * when
user goes to http://path2.com/ - {webapp}/path2 is served as root
path
is it possible?
What you are saying is nonsensical (specifically, the part where you
say that you want /path1 to be mapped to root.
If you want two virtual hosts, then define two virtual hosts. If you
want an app on each host configured as ROOT, then make your two
virtual hosts have two separate appBase directories (which should be a
requirement in the first place of two virtual hosts) and toss a copy
of your WAR file in each appBase, both named ROOT.war (cApITaLS matter).
You can't deploy a single copy (in memory) of your webapp and expect
to get all your requirements above met. If you want to have a single
WAR file on the disk and deploy it multiple times, you *can* do that
but I'm not sure why anyone would want to.
looks like the goal is not reachable with plain tomcat configuration.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEC85cACgkQ9CaO5/Lv0PCsDACfYWSxsHAgIoFRDWPNGd+O3FvN
mtsAnji32K1aEfpIZPv0gRQWgvoV4Hnc
=RC5B
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/24/2013 5:32 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
BBQ,
On 1/23/13 12:09 AM, bxqdev wrote:
i need to map a custom paths, like /path1 and /path2, (not root
/ path), of the same webapp to a custom domains.
as i said i need this mapping: ${samewebapp}/path1 is mapped to
http://path1.com/ ${samewebapp}/path2 is mapped to
http://path2.com/
NOT this: ${samewebapp}/path1 is mapped to http://path1.com/path1
${samewebapp}/path2 is mapped to http://path2.com/path2
What is ${samewebpp}/path1? Is that a piece of a webapp?
yes, paths are the parts of one webapp
Do you care if the same webapp is deployed twice (which is probably
going to be required)?
i want to have one instance of webapp,
which has two paths,
and each of the paths servers the root of different domains
is it possible?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEAj0cACgkQ9CaO5/Lv0PCChwCggGZi3v8ylGaj6py+uQ2ZNuq9
0+QAnR5ENaqoollzjpB5dx7KtcT3mquu
=/GYF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
On 1/24/2013 11:52 AM, Casper Wandahl Schmidt wrote:
See inline
Med venlig hilsen/Kind regards
Casper W. Schmidt
Den 24-01-2013 02:32, Christopher Schultz skrev:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
BBQ,
On 1/23/13 12:09 AM, bxqdev wrote:
i need to map a custom paths, like /path1 and /path2, (not root
/ path), of the same webapp to a custom domains.
as i said i need this mapping: ${samewebapp}/path1 is mapped to
http://path1.com/ ${samewebapp}/path2 is mapped to
http://path2.com/
NOT this: ${samewebapp}/path1 is mapped to http://path1.com/path1
${samewebapp}/path2 is mapped to http://path2.com/path2
What is ${samewebpp}/path1? Is that a piece of a webapp?
Do you care if the same webapp is deployed twice (which is probably
going to be required)?
Actually the OP is not really clear in describing anything. I'm wondering if path1 in
http://path1.com equals path1 in the
/path1 part or not.
actually the path names and domain names should be able to be different
Anyway I would say a context.xml file in conf/catalina/path1 (the
hostname)/path1.xml (the context name) should do the trick?
Place the webapp outside the appbase of the hosts and then point the docbase to
the webapp (or just drop the .war with two
different names in the appbases of the two hosts) :)
i want to have one instance of webapp,
which has two paths,
and each of the paths serves the root of different domains
once again:
* one webapp
* has 2 different paths: /path1 and /path2
* served on 2 domains
* when user goes to http://path1.com/ - {webapp}/path1 is served as root path
* when user goes to http://path2.com/ - {webapp}/path2 is served as root path
is it possible?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEAj0cACgkQ9CaO5/Lv0PCChwCggGZi3v8ylGaj6py+uQ2ZNuq9
0+QAnR5ENaqoollzjpB5dx7KtcT3mquu
=/GYF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different webapp paths on different hosts
i need to map a custom paths, like /path1 and /path2, (not root / path),
of the same webapp to a custom domains.
as i said i need this mapping:
${samewebapp}/path1 is mapped to http://path1.com/
${samewebapp}/path2 is mapped to http://path2.com/
NOT this:
${samewebapp}/path1 is mapped to http://path1.com/path1
${samewebapp}/path2 is mapped to http://path2.com/path2
custom paths of the same webapp should map to different root paths on different
domains.
thanks!
On 1/23/2013 8:58 AM, Caldarale, Charles R wrote:
From: bxqdev [mailto:bxq...@themailbay.com]
Subject: Different webapp paths on different hosts
Is it possible with tomcat to have one web app, with 2 different
paths on different hosts??
I mean something like this:
${samewebapp}/path1 is mapped to http://path1.com/
and
${samewebapp}/path2 is mapped to http://path2.com/
Assuming path1.com and path2.com evaluate to the same IP address (or at least to the
same system), this will happen automatically with a single Host element in
the Tomcat configuration.
Or did you really want to ask a different question?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 6:33 AM, Terence M. Bandoian wrote: How much is a lot? 10'000/sec How many Tomcats are you running? 1 How much RAM/CPU per server etc? 8GB/Xeon How big is the average response? 300Kb How many NICs do you have? Have fast are they? one. as i said above, the actual traffic is less than 1Gb/sec. don't pay attention to technical details of my hardware. the question is theoretical. i want to understand what each combination of connector+servlet api is intended for. my service works pretty well, i'm just looking forward, but most repliers don't know the subject well, so they can't explain. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 12:09 PM, Pid * wrote: On 27 Jan 2012, at 23:53, bxqdevbxq...@themailbay.com wrote: On 1/28/2012 3:41 AM, Pid wrote: On 27/01/2012 23:35, bxqdev wrote: On 1/28/2012 3:16 AM, Pid wrote: On 27/01/2012 22:51, bxqdev wrote: On 1/28/2012 2:39 AM, Pid wrote: On 27/01/2012 21:35, bxqdev wrote: On 1/28/2012 1:16 AM, Pid wrote: On 27/01/2012 21:06, bxqdev wrote: On 1/27/2012 8:27 PM, Pid wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? Eh? Is that what you really mean? i mean what are the reasons to use either connector variant. NIO can handle more concurrent connections. yeah, that's why i use the nio connector. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? What advantages are you looking for? How much traffic are you expecting to handle? a lot of. i'm looking for advantages in throughput and performance, for example. How much is a lot? 10'000/sec How many Tomcats are you running? 1 How much RAM/CPU per server etc? 8GB/Xeon Only 1 CPU? yes, but it's multicore. How big is the average response? 300Kb So you want to send 300k * 1 / sec? Isn't that just under 3Gb per second? actually when i measured it was less than 1Gb/sec I see. Did you identify where the bottleneck was? well, we are getting too far from the subject. can you make up 3 cases when to use 3 combinations of connector+servlet api 1. bio connector + async servlet 2. nio connector + sync servlet 3. nio connector + async servlet i mean in which theoretical case each combination of connector+servlet api is the best choice? Nope. it's not that hard, when you know the subject, but i guess, unfortunately, it's not the case :) Oh, that's even more crude than my baiting. Aside from which Mark already gave a reasonable answer. well, nothing personal. but if you can't explain - you don't know by yourself. that's the rule :) 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. How have you optimised your application so far, or are you hoping to optimise Tomcat first? webapp is optimized, i want to optimize tomcat. How did you optimise your webapp for 3Gb/sec with only 8Gb of RAM? i wrote nice code. it's serving 1Gb/sec with 8Gb of RAM. are you surprised? No, I'm curious*. Of course you mean8Gb for the JVM process, as the OS etc consumes ~1.5Gb usually, you want to leave a bit of space too, so usually end up aiming for 4Gb for the JVM unless you want to use swap as well. Are you using swap to improve your memory performance? is it some kind of sarcasm? Yep. ok, very funny. In 3 seconds you'll have produced more data than you have RAM, how have you optimised the garbage collector for this? we use a custom garbage collector. Interesting. Of your own design? yes, we're going to opensource it soon. stay tuned. I shall. what garbage collector do you use? Depends. ok. can you enumerate them though? are you able to give detailed and comprehensive answers, besides yeps, nopes and depends? p I was going to ask whether you had a 64bit JVM and whether you found CompressedOops to be a performance improvement or not? why would we use 32bit OS/JVM on 8Gb server? actually we don't have any problems to solve. my question is more theoretical. * There's a few meanings to that, André, I know which one I meant. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
well, let's separate the wheat from the chaff and arrogance: 1. nio connector is useful when one needs to handle a lot of client connections, keep-alive ones, for example. 2. async servlet is useful when one app thread can fulfill many responses. 3. communication between connector and async servlet should be called semi-async, rather than async, because request processing is sync anyway, although response processing is async. that could be a simple answer for my question in the first place. everything else is triteness. thanks anyway :) thread can be closed now. On 1/28/2012 3:59 PM, Mark Thomas wrote: On 27/01/2012 23:16, bxqdev wrote: 2. async servlet api is not much usefull for servers, with nio connectors (tomcat-7). at least you can't image the case. I don't say that. In fact, I said exactly the opposite. well, then what's the case to use both of this technologies? can you make up a theoretical case for an example? Yes. See below. 3. async servlet api is some general technology to decouple client from server, when server doesn't have nio connector (server is bio-only). No. The Servlet Async API and the considerations for when one might use it are completely orthogonal to connector selection. how is that? both connector and servlet process user http request. one by one. how are they orthogonal? The Servlet API, including the Async API only provides blocking IO. I will ignore the APR/native connector since that just complicates things further and just consider the BIO and NIO connectors below. The fundamental difference is that BIO requires one thread per connection whereas NIO requires one thread per currently processing request plus a few threads for the pollers. Each poller can monitor several thousand connections. Therefore in a situation where you have many more connections than you have current requests (think lots of HTTP keep-alive) then NIO scales significantly better than BIO. The (very small) price you pay is performance since using a poller adds overhead to request processing. [1] shows that the NIO connector uses non-blocking IO where it can but as soon as it enters the realm of the Servlet API (reading the request body and writing the request response) it has to simulate blocking IO. There is actually a complication to BIO in newer versions of Tomcat. Rather than dedicating one thread to a connection, each time Tomcat needs to read from a connection (remember this is blocking IO and there might not be anything to read if the connection is in keep-alive but the thread will then block until some data turns up or the connection times out) Tomcat obtains a thread from an executor. This raises the possibility of having more connections than you have threads. With BIO that is usually bad and results in unexpected delays in processing requests but as we'll see shortly, there are times (not many) where it might be useful. Prior to the Servlet 3.0 Async API a single container thread was responsible for all of the processing associated with a request. A few points to note at this point: - All IO is still blocking IO - The async API is only for writing data to the response. There is no async reading of data from the client. A typical usage of the Servlet 3.0 Async API is as follows: - request processing starts as usual on a container thread - async is started - the container thread is returned to the container's thread pool - processing continues on an application thread - the application writes some data to the response - the application passes the response back to the container for the container to finish it off on a container thread The purpose of the Servlet 3.0 Async API is to remove the one thread per currently processing request constraint. This allows applications to do things like: - implement a stock ticker with one thread writing to many responses (rather than one thread per response) - implement a chat program with one thread writing to all the clients (rather than one thread per response) If applications relay on external resources that are known to take a long time to respond, prior to the Async API developers had no choice but to simply block waiting for the external resource to respond. With the Async API, a single thread can monitor an external resource on behalf of many requests and only dispatch the request/response pair to a container thread for processing when the external resource has replied. This allows for more efficient use of container threads. Now back to the BIO complication. Lets say you have 100 container threads configured on your BIO connector and you are absolutely sure that at any one time 20% of your incoming connections would be using Servlet 3 Async and would be being handled by an application thread then you could set maxConnections to 120 and service 120 users in parallel. Your assumption regarding the 20% was wrong then you would see potentially long delays in processing incoming requests as connections with data were waiting
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 5:01 PM, Pid wrote: On 28/01/2012 09:07, bxqdev wrote: snip I see. Did you identify where the bottleneck was? well, we are getting too far from the subject. can you make up 3 cases when to use 3 combinations of connector+servlet api 1. bio connector + async servlet 2. nio connector + sync servlet 3. nio connector + async servlet i mean in which theoretical case each combination of connector+servlet api is the best choice? Nope. it's not that hard, when you know the subject, but i guess, unfortunately, it's not the case :) Oh, that's even more crude than my baiting. Aside from which Mark already gave a reasonable answer. well, nothing personal. but if you can't explain - you don't know by yourself. that's the rule :) Still baiting, still not biting. I might refer to your own replies, in which you made certain claims without explaining how. you're trying to change the subject, the point is: you don't know enough to answer the original question. 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. snip yes, we're going to opensource it soon. stay tuned. I shall. what garbage collector do you use? Depends. ok. can you enumerate them though? are you able to give detailed and comprehensive answers, besides yeps, nopes and depends? Yep. unfortunately you've just proved the opposite :) p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 6:14 PM, Pid * wrote: On 28 Jan 2012, at 13:34, bxqdevbxq...@themailbay.com wrote: On 1/28/2012 5:01 PM, Pid wrote: On 28/01/2012 09:07, bxqdev wrote: snip I see. Did you identify where the bottleneck was? well, we are getting too far from the subject. can you make up 3 cases when to use 3 combinations of connector+servlet api 1. bio connector + async servlet 2. nio connector + sync servlet 3. nio connector + async servlet i mean in which theoretical case each combination of connector+servlet api is the best choice? Nope. it's not that hard, when you know the subject, but i guess, unfortunately, it's not the case :) Oh, that's even more crude than my baiting. Aside from which Mark already gave a reasonable answer. well, nothing personal. but if you can't explain - you don't know by yourself. that's the rule :) Still baiting, still not biting. I might refer to your own replies, in which you made certain claims without explaining how. you're trying to change the subject, the point is: you don't know enough to answer the original question. 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. snip yes, we're going to opensource it soon. stay tuned. I shall. what garbage collector do you use? Depends. ok. can you enumerate them though? are you able to give detailed and comprehensive answers, besides yeps, nopes and depends? Yep. unfortunately you've just proved the opposite :) Your reasoning is flawed and my contributions to this list over the years stand as evidence to the contrary. contribution of unrelated counter-questions to unanswered questions :) thanks anyway, at least you've tried :) Do let us know when you open source your garbage collector. sure! p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
andre, i'm sorry if i hurt your feelings and trust in humanity, try to be positive, try to look on the situation from another point of view, the one which is not depressive. i hope my question answer summary upgraded your level of tomcat understanding. and that's a good thing, because you wouldn't understand connectors async servlets so well, if i didn't post the question in the first place and make the answer summary in the second. i've already thanked both talkers, which makes me a very nice person :) and even though slow pid still doesn't understand anything and arrogant mark still searches for insignificant typos in my posts, i don't blame them for who they are :) i hope everyone enjoyed the thread. thanks everyone. behave well :) On 1/28/2012 8:36 PM, André Warnier wrote: Hi. Your original question was quote 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? 3. How do i choose which one to use in any particular case? unquote and your conclusion is : well, let's separate the wheat from the chaff and arrogance: 1. nio connector is useful when one needs to handle a lot of client connections, keep-alive ones, for example. 2. async servlet is useful when one app thread can fulfill many responses. 3. communication between connector and async servlet should be called semi-async, rather than async, because request processing is sync anyway, although response processing is async. that could be a simple answer for my question in the first place. everything else is triteness. thanks anyway :) thread can be closed now. If it were to happen that you would have a further need to make use of this list (or another similar help forum), may I suggest that you fist read and ponder the document at http://catb.org/esr/faqs/smart-questions.html. And if you have read it already, read it again, because you would seem to have missed its quintessence. I have just been watching this thread, as the underlying technique is far above my level. But to answer your claims of arrogance and triteness : It already took several exchanges to get you to correct the mistakes (or should I say the chaff?) in your question, which made it close to nonsensical in the first place. When the persons here who try to help posters in their enquiries asked you for clarification, your responses seemed to imply that they should have been smart enough to correct your own messiness, and that you could barely bother yourself to do so. Even after correction, your original questions were so open-ended that answering them in the manner you seemed to want, would have amounted to providing a free training manual in Connector code and the relevant aspects of the Servlet Specification. But throughout, you sounded as if such an answer was just your due, although you are neither paying for the software nor for the help. You did not appear to make any effort in providing information allowing the persons who were trying to help, to at least be able to focus their explanations and save their time (and yours). By doing this, you managed to goad someone into spending the time to correct your misunderstandings and misconceptions, and out of their comprehensive answers you then magnanimously extracted what was important for you, discarding the rest as chaff and triteness. So in the end you got what you probably wanted, and which you could have gotten much faster, and at less expense of someone else's time, if you had made an effort to write correct and focused questions in the first place. In this process, you also managed to expose yourself as an arrogant and egotistical asshole. I hope that the trade-off is worth it to you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connectors: Http11Protocol vs. Http11NioProtocol
Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? 3. How do i choose which one to use in any particular case? thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/27/2012 8:29 PM, Mark Thomas wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? There is no such protocol as apache.coyote.http11.Http11NioProtocol so if you try using it, that connector will fail to start. i assume you can guess that it's org.apache.coyote.http11.Http11NioProtocol 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector Yes. What are they? or do i have to use Async Servlet Api to get the advantages? No. ok 3. How do i choose which one to use in any particular case? a) Understand your requirements b) Read the docs, particularly [1] c) Choose the connector that best meets your requirements. it's a bit abstract. Java Blocking Connector Java Nio Blocking Connector BIO NIO Classname Http11Protocol Http11NioProtocol Tomcat Version 3.x onwards 6.x onwards Support Polling NO YES Polling Size N/A maxConnections Read HTTP Request Blocking Non Blocking Read HTTP BodyBlocking Sim Blocking Write HTTP Response Blocking Sim Blocking Wait for next Request Blocking Non Blocking SSL Support Java SSLJava SSL SSL Handshake Blocking Non blocking Max ConnectionsmaxConnections maxConnections It doesn't show how that corresponds to Sync vs Async Servlet APIs. actually it's interesting to know about the following cases: 1. Sync Servlet + Non Bloking NIO Connector 2. Async Servlet + Bloking IO Connector How are connector and servlet code related? Mark [1] http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/27/2012 8:27 PM, Pid wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? Eh? Is that what you really mean? i mean what are the reasons to use either connector variant. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? What advantages are you looking for? How much traffic are you expecting to handle? a lot of. i'm looking for advantages in throughput and performance, for example. 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. p thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 1:14 AM, Mark Thomas wrote: On 27/01/2012 21:03, bxqdev wrote: On 1/27/2012 8:29 PM, Mark Thomas wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? There is no such protocol as apache.coyote.http11.Http11NioProtocol so if you try using it, that connector will fail to start. i assume you can guess that it's org.apache.coyote.http11.Http11NioProtocol In which case they are identical since you are specifying the same class name. oh, i see. well, nio or io connectors. that's what i mean. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector Yes. What are they? As per the docs. You even quoted the comparison. 3. How do i choose which one to use in any particular case? a) Understand your requirements b) Read the docs, particularly [1] c) Choose the connector that best meets your requirements. it's a bit abstract. I suspect you need to read up (generally) on the differences between blocking and non-blocking IO. i know the differences. but it looks like there's 2 points of choice: 1. nio vs. io in connectors 2. nio vs. io in servlet api i don't understand how this choices are related. Java Blocking Connector Java Nio Blocking Connector BIO NIO Classname Http11Protocol Http11NioProtocol Tomcat Version 3.x onwards 6.x onwards Support Polling NO YES Polling Size N/A maxConnections Read HTTP Request Blocking Non Blocking Read HTTP BodyBlocking Sim Blocking Write HTTP Response Blocking Sim Blocking Wait for next Request Blocking Non Blocking SSL Support Java SSLJava SSL SSL Handshake Blocking Non blocking Max ConnectionsmaxConnections maxConnections It doesn't show how that corresponds to Sync vs Async Servlet APIs. Because there is no correlation. great. i thought there was though. actually it's interesting to know about the following cases: 1. Sync Servlet + Non Bloking NIO Connector 2. Async Servlet + Bloking IO Connector Know what? They both work. How well they work will depend on many factors outside of Tomcat's control. ok. How are connector and servlet code related? Again, read the docs: http://tomcat.apache.org/tomcat-7.0-doc/architecture/requestProcess/requestProcess.pdf i will. didn't know about the existence of that document. It is slightly old and probably not completely correct in all details for 7.0.x but should be good enough. that's bad. maybe you could explain in few words, as an expert? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 1:16 AM, Pid wrote: On 27/01/2012 21:06, bxqdev wrote: On 1/27/2012 8:27 PM, Pid wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? Eh? Is that what you really mean? i mean what are the reasons to use either connector variant. NIO can handle more concurrent connections. yeah, that's why i use the nio connector. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? What advantages are you looking for? How much traffic are you expecting to handle? a lot of. i'm looking for advantages in throughput and performance, for example. How much is a lot? 10'000/sec How many Tomcats are you running? 1 How much RAM/CPU per server etc? 8GB/Xeon How big is the average response? 300Kb 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. How have you optimised your application so far, or are you hoping to optimise Tomcat first? webapp is optimized, i want to optimize tomcat. p p thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 1:53 AM, Mark Thomas wrote: On 27/01/2012 21:31, bxqdev wrote: On 1/28/2012 1:14 AM, Mark Thomas wrote: On 27/01/2012 21:03, bxqdev wrote: On 1/27/2012 8:29 PM, Mark Thomas wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? There is no such protocol as apache.coyote.http11.Http11NioProtocol so if you try using it, that connector will fail to start. i assume you can guess that it's org.apache.coyote.http11.Http11NioProtocol In which case they are identical since you are specifying the same class name. oh, i see. well, nio or io connectors. that's what i mean. There is no IO connector. Tomcat 7 supports three connector variants: BIO, NIO APR/native. There are separate implementations of each for the HTTP and AJP protocols. well, i mean bio and nio connectors for http. I suspect you need to read up (generally) on the differences between blocking and non-blocking IO. i know the differences. Then why are you asking such basic questions about the differences between non-blocking IO and blocking IO? nevermind. but it looks like there's 2 points of choice: 1. nio vs. io in connectors 2. nio vs. io in servlet api There is no NIO support in the Servlet spec. The Servlet API uses entirely blocking IO throughout. There is Async support in Servlet 3.0 onwards which could be viewed as a form of non-blocking IO I guess but is really just a way to de-couple writing to the response and the thread processing the request/response pair. yes, that's what i call async servlet api. i don't understand how this choices are related. They aren't. If you want to understand what Servlet 3.0 async is, you need to read the Servlet 3.0 spec. How are connector and servlet code related? Again, read the docs: http://tomcat.apache.org/tomcat-7.0-doc/architecture/requestProcess/requestProcess.pdf i will. didn't know about the existence of that document. It is slightly old and probably not completely correct in all details for 7.0.x but should be good enough. that's bad. maybe you could explain in few words, as an expert? No fundamental changes. Replace thread pools with executors and the detail of the Protocol / Processor / Endpoint relationships (which is important to understand as soon as you starting working with the code) isn't shown but you don't really need that. Also, the Async behaviour isn't shown. ok, so what about this case: http nio connector + async servlet i would say that in this variant there're 2 points of asynchronism - both connector and servlet code are async. is there a case when i would need such a combination? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 2:28 AM, Mark Thomas wrote: On 27/01/2012 22:22, bxqdev wrote: ok, so what about this case: http nio connector + async servlet i would say that in this variant there're 2 points of asynchronism - both connector and servlet code are async. is there a case when i would need such a combination? Where someone might need that? Sure. Where you would need it? No idea. My crystal ball is looking rather foggy at the moment. If you have a specific question about a specific use case... so can i say that: 1. if one needs to decouple client from nio server (tomcat-7), nio connector can be used to solve that. 2. async servlet api is not much usefull for servers, with nio connectors (tomcat-7). at least you can't image the case. 3. async servlet api is some general technology to decouple client from server, when server doesn't have nio connector (server is bio-only). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 2:39 AM, Pid wrote: On 27/01/2012 21:35, bxqdev wrote: On 1/28/2012 1:16 AM, Pid wrote: On 27/01/2012 21:06, bxqdev wrote: On 1/27/2012 8:27 PM, Pid wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? Eh? Is that what you really mean? i mean what are the reasons to use either connector variant. NIO can handle more concurrent connections. yeah, that's why i use the nio connector. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? What advantages are you looking for? How much traffic are you expecting to handle? a lot of. i'm looking for advantages in throughput and performance, for example. How much is a lot? 10'000/sec How many Tomcats are you running? 1 How much RAM/CPU per server etc? 8GB/Xeon Only 1 CPU? yes, but it's multicore. How big is the average response? 300Kb So you want to send 300k * 1 / sec? Isn't that just under 3Gb per second? actually when i measured it was less than 1Gb/sec 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. How have you optimised your application so far, or are you hoping to optimise Tomcat first? webapp is optimized, i want to optimize tomcat. How did you optimise your webapp for 3Gb/sec with only 8Gb of RAM? i wrote nice code. it's serving 1Gb/sec with 8Gb of RAM. are you surprised? In 3 seconds you'll have produced more data than you have RAM, how have you optimised the garbage collector for this? we use a custom garbage collector. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 2:49 AM, Mark Thomas wrote: On 27/01/2012 22:41, bxqdev wrote: On 1/28/2012 2:28 AM, Mark Thomas wrote: On 27/01/2012 22:22, bxqdev wrote: ok, so what about this case: http nio connector + async servlet i would say that in this variant there're 2 points of asynchronism - both connector and servlet code are async. is there a case when i would need such a combination? Where someone might need that? Sure. Where you would need it? No idea. My crystal ball is looking rather foggy at the moment. If you have a specific question about a specific use case... so can i say that: 1. if one needs to decouple client from nio server (tomcat-7), nio connector can be used to solve that. Define decouple. make client connection and servlet code execute in different threads. asynchronously. 2. async servlet api is not much usefull for servers, with nio connectors (tomcat-7). at least you can't image the case. I don't say that. In fact, I said exactly the opposite. well, then what's the case to use both of this technologies? can you make up a theoretical case for an example? 3. async servlet api is some general technology to decouple client from server, when server doesn't have nio connector (server is bio-only). No. The Servlet Async API and the considerations for when one might use it are completely orthogonal to connector selection. how is that? both connector and servlet process user http request. one by one. how are they orthogonal? I am getting rather bored with this. Please go and read up on blocking IO vs. non-blocking IO and then read the Async parts of the Servlet 3.0 specification. Then come back here and try asking some more focussed questions. i completely understand the difference of bio vs. nio. and i've already read async servlet spec. both technologies decouple (make async) input and output. but i can't imagine the case when the one would need two points of decoupling on one processing chain. 1. bio connector sync servlet 1.1 i guess everything is obvious 2. bio connector async servlet 2.1 bio connector receives request and synchronously handles it to async servlet 2.2 async servlet starts async processing code and returns. 2.3 bio connector waits async servlet to finish 2.4 async servlet fullfills response 2.5 bio connector returns servlet to client 3. nio connector sync servlet 3.1 nio connector makes select and receives http request 3.2 nio connector handles request to sync servlet 3.3 sync servlet processes request and return response 3.4 nio connector makes select and receives http response from sync servlet 3.5 nio connector returns servlet to client 4. nio connector async servlet 4.1 nio connector makes select and receives http request 4.2 nio connector handles request to async servlet 4.3 async servlet starts async processing code. 4.4 async servlet fullfills response 4.5 nio connector makes select and receives http response from async servlet 4.6 nio connector returns servlet to client uh, that was a lot of typing :) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 3:16 AM, Pid wrote: On 27/01/2012 22:51, bxqdev wrote: On 1/28/2012 2:39 AM, Pid wrote: On 27/01/2012 21:35, bxqdev wrote: On 1/28/2012 1:16 AM, Pid wrote: On 27/01/2012 21:06, bxqdev wrote: On 1/27/2012 8:27 PM, Pid wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? Eh? Is that what you really mean? i mean what are the reasons to use either connector variant. NIO can handle more concurrent connections. yeah, that's why i use the nio connector. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? What advantages are you looking for? How much traffic are you expecting to handle? a lot of. i'm looking for advantages in throughput and performance, for example. How much is a lot? 10'000/sec How many Tomcats are you running? 1 How much RAM/CPU per server etc? 8GB/Xeon Only 1 CPU? yes, but it's multicore. How big is the average response? 300Kb So you want to send 300k * 1 / sec? Isn't that just under 3Gb per second? actually when i measured it was less than 1Gb/sec I see. Did you identify where the bottleneck was? well, we are getting too far from the subject. can you make up 3 cases when to use 3 combinations of connector+servlet api 1. bio connector + async servlet 2. nio connector + sync servlet 3. nio connector + async servlet i mean in which theoretical case each combination of connector+servlet api is the best choice? 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. How have you optimised your application so far, or are you hoping to optimise Tomcat first? webapp is optimized, i want to optimize tomcat. How did you optimise your webapp for 3Gb/sec with only 8Gb of RAM? i wrote nice code. it's serving 1Gb/sec with 8Gb of RAM. are you surprised? No, I'm curious*. Of course you mean 8Gb for the JVM process, as the OS etc consumes ~1.5Gb usually, you want to leave a bit of space too, so usually end up aiming for 4Gb for the JVM unless you want to use swap as well. Are you using swap to improve your memory performance? is it some kind of sarcasm? In 3 seconds you'll have produced more data than you have RAM, how have you optimised the garbage collector for this? we use a custom garbage collector. Interesting. Of your own design? yes, we're going to opensource it soon. stay tuned. I was going to ask whether you had a 64bit JVM and whether you found CompressedOops to be a performance improvement or not? why would we use 32bit OS/JVM on 8Gb server? actually we don't have any problems to solve. my question is more theoretical. p * There's a few meanings to that, André, I know which one I meant. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connectors: Http11Protocol vs. Http11NioProtocol
On 1/28/2012 3:41 AM, Pid wrote: On 27/01/2012 23:35, bxqdev wrote: On 1/28/2012 3:16 AM, Pid wrote: On 27/01/2012 22:51, bxqdev wrote: On 1/28/2012 2:39 AM, Pid wrote: On 27/01/2012 21:35, bxqdev wrote: On 1/28/2012 1:16 AM, Pid wrote: On 27/01/2012 21:06, bxqdev wrote: On 1/27/2012 8:27 PM, Pid wrote: On 27/01/2012 14:53, bxqdev wrote: Hello, Developers! 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol connectors? Eh? Is that what you really mean? i mean what are the reasons to use either connector variant. NIO can handle more concurrent connections. yeah, that's why i use the nio connector. 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to get the advantages? What advantages are you looking for? How much traffic are you expecting to handle? a lot of. i'm looking for advantages in throughput and performance, for example. How much is a lot? 10'000/sec How many Tomcats are you running? 1 How much RAM/CPU per server etc? 8GB/Xeon Only 1 CPU? yes, but it's multicore. How big is the average response? 300Kb So you want to send 300k * 1 / sec? Isn't that just under 3Gb per second? actually when i measured it was less than 1Gb/sec I see. Did you identify where the bottleneck was? well, we are getting too far from the subject. can you make up 3 cases when to use 3 combinations of connector+servlet api 1. bio connector + async servlet 2. nio connector + sync servlet 3. nio connector + async servlet i mean in which theoretical case each combination of connector+servlet api is the best choice? Nope. it's not that hard, when you know the subject, but i guess, unfortunately, it's not the case :) 3. How do i choose which one to use in any particular case? First, don't prematurely optimise. Have you tested your application yet? yes, i need a better throughput and performance. Please provide details. How have you optimised your application so far, or are you hoping to optimise Tomcat first? webapp is optimized, i want to optimize tomcat. How did you optimise your webapp for 3Gb/sec with only 8Gb of RAM? i wrote nice code. it's serving 1Gb/sec with 8Gb of RAM. are you surprised? No, I'm curious*. Of course you mean 8Gb for the JVM process, as the OS etc consumes ~1.5Gb usually, you want to leave a bit of space too, so usually end up aiming for 4Gb for the JVM unless you want to use swap as well. Are you using swap to improve your memory performance? is it some kind of sarcasm? Yep. ok, very funny. In 3 seconds you'll have produced more data than you have RAM, how have you optimised the garbage collector for this? we use a custom garbage collector. Interesting. Of your own design? yes, we're going to opensource it soon. stay tuned. I shall. what garbage collector do you use? p I was going to ask whether you had a 64bit JVM and whether you found CompressedOops to be a performance improvement or not? why would we use 32bit OS/JVM on 8Gb server? actually we don't have any problems to solve. my question is more theoretical. * There's a few meanings to that, André, I know which one I meant. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
