tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <karl.kil...@gmail.com>
Subject Re: measure session size?
Date Mon, 09 Feb 2015 14:44:47 GMT
Hello,

Yes agreed. I meant to say that I find xrebel stuff unsuitable for tracing
production so I will keep some kind of homebrewed session measurement even
if I end up liking xrebel. Iterating over the attributes in the session
would be nice except you do you get the keySet / entry / map? I am still
using the reflection hack that required policy change

cheers


On 9 February 2015 at 15:25, Mark Struberg <struberg@yahoo.de> wrote:

> I'd not enable any of the filters or jRebell in production.
>
> If you really need that in production and you know that you have
> Tomcat/TomEE then there are better tools which can report session
> staticstics via JMX on demand.
>
> Might be too expensive to do it on each request in production.
>
> LieGrue,
> strub
>
>
>
>
> > On Monday, 9 February 2015, 15:05, Karl Kildén <karl.kilden@gmail.com>
> wrote:
> > > XRebel is on the todo list but it's good to able to log it in
> production.
> >
> > Thanks alot Romain and Mark for the information!
> >
> >
> > On 9 February 2015 at 11:26, Mark Struberg <struberg@yahoo.de> wrote:
> >
> >>  Often both numbers are interesting.
> >>
> >>
> >>  The complete session size is important to know as it tells you how much
> >>  memory you need (before having to swap sessions to disc). And often
> devs
> >>  put way too much stuff into the session without noticing.
> >>
> >>  The delta-size is important for the network traffic on 'real'
> > clustering.
> >>  But be aware that there is no specified way to know what parts of the
> >>  session account for a delta. In Tomcat an attribute gets
> delta-replicated
> >>  ONLY if the attribute gets set.
> >>
> >>
> >>  E.g. if you have a Map<String, String> vals; and set this into the
> > session
> >>  once and then just change the content, then this attribute will NOT get
> >>  delta-replicated by Tomcat! (Despite it's content did change). You will
> >>  need an explicit set on that attribute.
> >>
> >>  But be aware that this might trigger another dead spot in the servlets
> >>  spec. Tomcat does detect that you set the same attribute instance
> again and
> >>  will NOT fire a attribute destroyed event. So Tomcat _actively_
> suppresses
> >>  the destroy event in that very case. But other containers do not. They
> will
> >>  simply destroy your 'old' attribute value (which is actually the
> > same as
> >>  the 'new' one) and your application might blow up.
> >>
> >>  Long story short: if you activate delta-replication then you leave the
> >>  portable route and you need to know excactly what YOUR container does
> in
> >>  that case.
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>
> >>
> >>
> >>  > On Wednesday, 4 February 2015, 20:38, Romain Manni-Bucau <
> >>  rmannibucau@gmail.com> wrote:
> >>  > > after all this effort you'll maybe be disappointed. For
> > clustering (in
> >>  > particular tomcat one) what is important is not session size but
> delta
> >>  > size and throughoutput. typically if your session does 10M but only
> >>  > 200b are moving between nodes once a user is conencted for instance
> >>  > this is fine. About 1.5K then it depends as usual of your contraints
> >>  > and infra. Best way to know is to measure performances and
> > "cost"
> >>  > (cloud network is not always free for instance). Once you have it you
> >>  > can compare it to what you would like / what you can accept. There is
> >>  > no general rule sadly
> >>  >
> >>  >
> >>  > Romain Manni-Bucau
> >>  > @rmannibucau
> >>  > http://www.tomitribe.com
> >>  > http://rmannibucau.wordpress.com
> >>  > https://github.com/rmannibucau
> >>  >
> >>  >
> >>  > 2015-02-04 20:31 GMT+01:00 Karl Kildén <karl.kilden@gmail.com>:
> >>  >>  OK so I did
> >>  >>
> >>  >>  grant codeBase
> > "file:${catalina.home}/webapps/myapp/-"
> >>  > {
> >>  >>          permission java.security.AllPermission;
> >>  >>
> >>  >>  };
> >>  >>
> >>  >>
> >>  >>  https://gist.github.com/karlkilden/51233a012071a8f82c26
> >>  >>
> >>  >>  It works... Thanks - I was not very comfortable editing the
> > security
> >>  policy
> >>  >>  then again we do hosting and one app per TomEE so it hardly
> > matters
> >>  anyway.
> >>  >>
> >>  >>  My session size seems to be 1.5KB I wonder if that's to large
> > for a
> >>  >>  clustering setup? I think I will use the JDBC storage one for
> >>  clustering
> >>  >>  and use sticky sessions
> >>  >>
> >>  >>  cheers
> >>  >>
> >>  >>  On 4 February 2015 at 20:01, Romain Manni-Bucau
> >>  > <rmannibucau@gmail.com>
> >>  >>  wrote:
> >>  >>
> >>  >>>  sure
> >>  >>>
> >>  >>>
> >>  >>>  Romain Manni-Bucau
> >>  >>>  @rmannibucau
> >>  >>>  http://www.tomitribe.com
> >>  >>>  http://rmannibucau.wordpress.com
> >>  >>>  https://github.com/rmannibucau
> >>  >>>
> >>  >>>
> >>  >>>  2015-02-04 19:59 GMT+01:00  <karl.kilden@gmail.com>:
> >>  >>>  > Tried it, tomcat kills the thread and logs a security
> > something
> >>  >>>  exception. Guess i would need to turn off security manager
> >>  >>>  >
> >>  >>>  > Skickat från min iPhone
> >>  >>>  >
> >>  >>>  >> 4 feb 2015 kl. 19:52 skrev Romain Manni-Bucau
> >>  > <rmannibucau@gmail.com>:
> >>  >>>  >>
> >>  >>>  >> @Karl: if you didnt wrap it just use session fielf
> > of the
> >>  > session you
> >>  >>>  >> get (by reflection). Should be serializable
> >>  >>>  >>
> >>  >>>  >>
> >>  >>>  >> Romain Manni-Bucau
> >>  >>>  >> @rmannibucau
> >>  >>>  >> http://www.tomitribe.com
> >>  >>>  >> http://rmannibucau.wordpress.com
> >>  >>>  >> https://github.com/rmannibucau
> >>  >>>  >>
> >>  >>>  >>
> >>  >>>  >> 2015-02-04 19:49 GMT+01:00
> > <karl.kilden@gmail.com>:
> >>  >>>  >>> Hello Mark, httpsession does not implement
> > Serializable
> >>  > and tomcat
> >>  >>>  sessionholder does not. The actual session is not obtainable
> > :(
> >>  >>>  >>>
> >>  >>>  >>> Skickat från min iPhone
> >>  >>>  >>>
> >>  >>>  >>>> 4 feb 2015 kl. 16:52 skrev Mark Struberg
> >>  > <struberg@yahoo.de>:
> >>  >>>  >>>>
> >>  >>>  >>>> did that via a SerlvetFilter and just
> > serialized the
> >>  > session into a
> >>  >>>  byte[] and output the size. As benefit you also see early on
> > whether
> >>  > you
> >>  >>>  have something which is not properly Serializable and would
> > fail on a
> >>  >>>  cluster.
> >>  >>>  >>>>
> >>  >>>  >>>> LieGrue,
> >>  >>>  >>>> strub
> >>  >>>  >>>>
> >>  >>>  >>>>
> >>  >>>  >>>>
> >>  >>>  >>>>
> >>  >>>  >>>>
> >>  >>>  >>>>>> On Monday, 2 February 2015, 20:01,
> > Karl Kildén
> >>  > <
> >>  >>>  karl.kilden@gmail.com> wrote:
> >>  >>>  >>>>>> Hello!
> >>  >>>  >>>>>
> >>  >>>  >>>>> Anyone got some ideas on how to measure
> > session
> >>  > size?
> >>  >>>  >>>>>
> >>  >>>  >>>>> I serialized the JSF sessionmap and it
> > gave some
> >>  > hints but seems not
> >>  >>>  >>>>> everything is there. If I CDI scope with
> > Session
> >>  > and put a lot of
> >>  >>>  stuff in
> >>  >>>  >>>>> my bean the JSF map does not grow and I
> > can't
> >>  > figure out how to
> >>  >>>  serialize
> >>  >>>  >>>>> the session manually...
> >>  >>>  >>>>>
> >>  >>>  >>>>> If anyone knows exactly how viewstate
> > and
> >>  > sessionstate is stored for
> >>  >>>  a
> >>  >>>  >>>>> modern CDI/JSF application I would be
> > glad to hear
> >>  > about some
> >>  >>>  internals.
> >>  >>>  >>>>>
> >>  >>>  >>>>> I have no issues - just want to know
> > this so I can
> >>  > keep tabs as my
> >>  >>>  app grows
> >>  >>>  >>>>>
> >>  >>>  >>>>> cheers
> >>  >>>  >>>>>
> >>  >>>
> >>  >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message