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]
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=216&highlight=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=216&highlight=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]
