How to? debug large session size? drill down and tools / over 400K is too be for replication
users@tomcat.apache.org We have an application that has a pretty large session size ( 400K). This is causing issues for scalability and makes session replication for fail over quite impractical. What can be used to drill down live and generate a runtime report (perhaps a graph too) showing what http session attributes are the memory hog? We are looking to see not just the attribute that is the issue but perhaps the aggregate (or aggregate of aggregate) of the session attributes and their size in memory. Thanks! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to? debug large session size? drill down and tools / over 400K is too be for replication
I use www.yourkit.com Filip hanasaki jiji wrote: users@tomcat.apache.org We have an application that has a pretty large session size ( 400K). This is causing issues for scalability and makes session replication for fail over quite impractical. What can be used to drill down live and generate a runtime report (perhaps a graph too) showing what http session attributes are the memory hog? We are looking to see not just the attribute that is the issue but perhaps the aggregate (or aggregate of aggregate) of the session attributes and their size in memory. Thanks! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: How to? debug large session size? drill down and tools / over 400K is too be for replication
We use Lambda Probe http://www.lambdaprobe.org here -Mensagem original- De: hanasaki jiji [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 16 de outubro de 2007 15:53 Para: users@tomcat.apache.org Assunto: How to? debug large session size? drill down and tools / over 400K is too be for replication users@tomcat.apache.org We have an application that has a pretty large session size ( 400K). This is causing issues for scalability and makes session replication for fail over quite impractical. What can be used to drill down live and generate a runtime report (perhaps a graph too) showing what http session attributes are the memory hog? We are looking to see not just the attribute that is the issue but perhaps the aggregate (or aggregate of aggregate) of the session attributes and their size in memory. Thanks! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to? debug large session size? drill down and tools / over 400K is too be for replication
I should have mentioned we are using websphere ... looks like there is no support http://forums.yourkit.com/viewtopic.php?t=216highlight=ibm Other thoughts? On 10/16/07, Milanez, Marcus [EMAIL PROTECTED] wrote: We use Lambda Probe http://www.lambdaprobe.org here -Mensagem original- De: hanasaki jiji [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 16 de outubro de 2007 15:53 Para: users@tomcat.apache.org Assunto: How to? debug large session size? drill down and tools / over 400K is too be for replication users@tomcat.apache.org We have an application that has a pretty large session size ( 400K). This is causing issues for scalability and makes session replication for fail over quite impractical. What can be used to drill down live and generate a runtime report (perhaps a graph too) showing what http session attributes are the memory hog? We are looking to see not just the attribute that is the issue but perhaps the aggregate (or aggregate of aggregate) of the session attributes and their size in memory. Thanks! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to? debug large session size? drill down and tools / over 400K is too be for replication
We run across tomcat, websphere, BEA and currently are only working in websphere. Others to follow. On 10/16/07, hanasaki jiji [EMAIL PROTECTED] wrote: I should have mentioned we are using websphere ... looks like there is no support http://forums.yourkit.com/viewtopic.php?t=216highlight=ibm Other thoughts? On 10/16/07, Milanez, Marcus [EMAIL PROTECTED] wrote: We use Lambda Probe http://www.lambdaprobe.org here -Mensagem original- De: hanasaki jiji [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 16 de outubro de 2007 15:53 Para: users@tomcat.apache.org Assunto: How to? debug large session size? drill down and tools / over 400K is too be for replication users@tomcat.apache.org We have an application that has a pretty large session size ( 400K). This is causing issues for scalability and makes session replication for fail over quite impractical. What can be used to drill down live and generate a runtime report (perhaps a graph too) showing what http session attributes are the memory hog? We are looking to see not just the attribute that is the issue but perhaps the aggregate (or aggregate of aggregate) of the session attributes and their size in memory. Thanks! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
