ryan,
Wow! You get 1 million unique hits a month (1 unique hit every 2 seconds) handled by
a single pc running linux. That's awesome! When I was originally writing, I didn't
realize you were dealing with live, production issues... I hope I can help.
In my office I don't have direct access to that kind of load, and so I have to
simulate it. My original comments were more coming from that direction: I pictured
you running some home-grown load test which forgot to take cookies into account, and
consequently was experiencing a memory spike.
In real production usage almost all the clients support cookies. Very rare for a
person to have "cookies" disabled in their browser.
>So you are saying that possible it is not only creating a new session
>per new user but per page each user accesses?
>If so please teach me how to fix my problems with my coding.
The good news in reply to this: a new session per page access is (very) unlikely. I
didn't mean to scare you. I didn't realize the performance problems you were
reporting were real life. My thinking originally had me imagining that a problem like
you were experiencing would come from over-zealous simulation. The bad news is, I
guess, that your problem is currently impairing your production website!
>I do not use cookies and I do not call
>"session.setMaxInactiveInterval()" or
>"session.invalidate()" or response.encodeURL(). In fact I am completely
>ignorant about these calls. I assume my sessions are closed automatically
>by tomcat when there is no usage from that client for 15 minutes. So can
>I assume session.invalidate() kills a session. How and in what situation
>would I use this method?
If you ever use "session.setAttribute()" or "session.getAttribute()" in a jsp, then
you are using cookies. There's a chance you are using URL rewriting instead, but
that's not the default behaviour. The default behaviour is to use cookies. Tomcat
will do this whether you use the "session" object or not, but it only starts to weigh
down your application when you start calling "setAttribute()" on it. For example,
this would be suicide:
=================================
suicide.jsp
=================================
<%
// Allocate huge StringBuffer:
StringBuffer buf = new StringBuffer( 1000000 );
session.setAttribute( "Big-Waste-O-Space", buf );
%>
<html>
<head>
<title>Help!</title>
</head>
<body>
<h1>Help!</h1>
<p>I'm running out of memory!</p>
</body>
</html>
=================================
On the other hand, you'd have a hard time noticing:
=================================
session.setAttribute( "Small-Waste-O-Space", new Integer( 42 ) );
=================================
Now, a short tutorial. Since http is stateless, the concept of a "session" takes some
effort. How does Tomcat remember the user?
Let's use, for example, this jsp, named "hello.jsp":
=================================
hello.jsp
=================================
<% Object o = session; %>
<html>
<head>
<title>Welcome</title>
</head>
<body>
<h1>Hello</h1>
<p>Welcome to my page.</p>
</body>
</html>
=================================
As you can see, the "session" object is mentioned by name. But nothing interesting is
done to it. Look at the headers Tomcat responds with, however, when I try to telnet
into my server:
=================================
haplo $ telnet localhost 8080
Trying...
Connected to localhost.
Escape character is '^]'.
GET /hello.jsp HTTP/1.0 <-- I'm typing this by hand.
HTTP/1.1 200 OK
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Date: Tue, 03 Dec 2002 05:34:43 GMT
Server: Apache Tomcat/4.0.4-b2 (HTTP/1.1 Connector)
Set-Cookie: JSESSIONID=24BF830B73E7C313909FC4255DD3CD44;Path=/
<html>
<head>
<title>Welcome</title>
</head>
<body>
<h1>Hello</h1>
<p>Welcome to my page.</p>
</body>
</html>
Connection closed.
=================================
That "Set-Cookie" header is the cookie Tomcat expects me to quote back to it on any
subsequent requests I may make from now on. That's how the notion of a "session" is
possible: big random strings that no-one else in their right mind would ever think to
mention in their day-to-day http requests.
Watch what a modern browser then says on a subsequent request (as opposed to my
hand-typing telnet browser :-] ):
=================================
GET /index.jsp HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2a) Gecko/20020913
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
n;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: JSESSIONID=24BF830B73E7C313909FC4255DD3CD44
Cache-Control: max-age=0
=================================
The difference is small: the server says "Set-Cookie:" and the browser says "Cookie:".
Notice how I'm cheating: I cut & paste the original JSESSIONID from my telnet session
into this one. That's called "hijacking" a session. My Mozilla browser is now
masquerading as my original telnet browser. Tomcat thinks they are the same person.
Okay, that was probably too confusing... consider it a joke for the Tomcat-User list.
But, I hope you see how it works: Tomcat provides ("Set-Cookie:") a special "secret
code" for the browser to identify itself with from then on. By even coming up with
that "secret code", Tomcat has to allocate some resources so that Tomcat can later
recognize that same code when it is quoted back ("Cookie:") by the browser. As you
can imagine, Tomcat probably gives out more secret codes than it ends up getting
back... people might leave the site after the first page, or their browser might just
not support that header:
Cookie: JSESSIONID=24BF830B73E7C313909FC4255DD3CD44
That doesn't mean Tomcat can afford to forget any of them.
If Tomcat doesn't recieve the "secret code" (the cookie) for a specified amount of
time, in your case, 15 minutes, Tomcat forgets about it. The code and the objects
associated with the session are dropped.
In summary: in real-life use, the abstraction of a "session" provided to jsp writers
by Tomcat and other web containers is going to work perfectly fine, with no resource
compromise. Your well-designed application already needed those resources stored in
the session anyway. Sessions only add a few more references/pointers (at 4 bytes a
shot - cheap!) to those resources.
Over 99% of browsers support cookies. There are no hidden dangers with sessions.
Now, onto the rest of email.
> I assume session.invalidate() kills a session. How and in what situation
would I use this method?
Use it on a "logoff.jsp". Inside "logoff.jsp" just paste:
============================
<% session.invalidate() %>
============================
> I assume my sessions are closed automatically
by tomcat when there is no usage from that client for 15 minutes.
That is correct. Tomcat probably calls "invalidate()" just like you would on a
"logoff.jsp" page. Code re-use. :-)
> What does setMaxInactiveInterval do and how is that applied?
You could use this to override the 15 minute application-wide timeout you've
configured on a per/jsp or per/servlet basis. For example, maybe you would like to
set you "login.jsp's" session timeout to 2 minutes, but after the user successfully
logs in set it back to 15 minutes. This way people who fail to login, or don't bother
trying, use up less session resources. However, once you've set the session to 2
minutes on one page, it's going to stay 2 minutes unless you state otherwise somewhere
else.
I imagine that would work. I wouldn't bother messing around like that, though. Too
finicky. Buy a 2nd server and cluster them. :-)
> And same questions on response.encodeURL()?
This only applies if you're not using cookies. But it's not a bad idea - makes your
application more portable, since the cookie/no-cookie configuration is administrator
controlled, not developer controlled. Basically you run every internal link (to other
jsps or servlets) through "encodeURL()", et voila, sessions without cookies if ever
needed. I haven't used this, so my explanation here may be a little fluffy.
>Tomcat starts out with 128 megs and baloons up pretty quickly to 300 megs. It
>often exceeds that, there also seems to be a huge thread count.
Perhaps you have a thread problem (yikes!). My experience with threads and Tomcat is
very minimal, but in my experience threads use a lot of memory. I believe they keep
references to their entire call-stack (methods calling methods), and so when they hang
a lot of references remain unavailable to the garbage collector. Don't worry about
Tomcat: in my experience on this mailing list Tomcat's thread usage is perfect. It's
always developers that mess up. Don't feel bad if this is the case. You only get
good (err... marginally less dangerous) by screwing up several times. I almost took
down a medium sized financial institution's website I was developing due to some
shoddy thread work. Debugging multi-threaded apps when the threads go bad is fun in a
way.
The thing to remember with web applications is that each request, from start to
finish, is going to need a thread. If the thread gets lost somewhere along the way,
it's not coming back. Some tricks that seem to work for me (see what Tomcat-User
thinks):
Don't use wait() when you can use wait( 60000 )! At least you'll recover the thread a
minute later.
Don't use notify(). Use notifyAll() instead.
In my opinion "wait(void)" and "notify()" are not meant for mortals. Especially not
in conjunction with web applications.
Good luck, ryan! Hopefully we can help you fix your website, and help Tomcat conquer
the world!
It would be a good idea to try and isolate your problem. Can you get the memory usage
to balloon up during a simulation in a test environment? Of course, you're probably
frantically trying to fix your production site... in which case banging out
fear-inspired fixes can also work quite well, too.
I do envy your close proximity to such a respectable load on your computer. I wish I
could see what my own code would do at such use. My company plays it too safe to ever
know: when the CPU hits 35% in top, they add a new computer to the cluster.
yours,
Julius
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Mon 12/2/2002 2:31 PM
To: Julius Davies
Cc: Tomcat Users List
Subject: RE: Memory/Performance
Thanks for replying I think you are on the right track i must not be doing
something right here. You certainly got me confused and that can only be a
step in the right direction. I have my session-timeout set to 15. My load
is being generated from massive usage i get a million unique hits a month
and have a lot of customers simultaneously logged in at once. Tomcat
starts out with 128 megs and baloons up pretty quickly to 300 megs. It
often exceeds that, there also seems to be a huge thread count.
I do not use cookies and I do not call
"session.setMaxInactiveInterval()" or
"session.invalidate()" or response.encodeURL(). In fact I am completely
ignorant about these calls. I assume my sessions are closed automatically
by tomcat when there is no usage from that client for 15 minutes. So can
I assume session.invalidate() kills a session. How and in what situation
would I use this method?
What does setMaxInactiveInterval do and how is that applied?
And same questions on response.encodeURL()?
So you are saying that possible it is not only creating a new session
per new user but per page each user accesses?
If so please teach me how to fix my problems with my coding.
-ryan
On Mon, 2 Dec 2002, Julius Davies wrote:
>
> Developer,
>
> Hello. I use Tomcat 4.1.12 standalone. I was just thinking about what you were
>saying, especially "[...] I would think the memory stamp would correspondingly shrink
>when all these sessions are closed and it doesn't".
>
> I noticed this section in the default "web.xml":
>
> <!-- ==================== Default Session Configuration ================= -->
> <!-- You can set the default session timeout (in minutes) for all newly -->
> <!-- created sessions by modifying the value below. -->
>
> <session-config>
> <session-timeout>30</session-timeout>
> </session-config>
>
> So, by default on my machine sessions will stay around for 30 minutes, unless either
>"session.setMaxInactiveInterval()" or "session.invalidate()" was called. I haven't
>changed this file since I installed Tomcat, and so I'm assuming you have the same
>file.
>
> Are you calling either of those methods - invalidate or setMaxInactiveInterval? Or
>when you say "these sessions are closed", do you mean they time out after 30 minutes?
>
> Secondly, what are you doing to generate all this (server-crashing!) load?
>Obviously you're not going to call "session.invalidate()" on the same page that you
>created the session. That would be pointless... so here comes an interesting
>possibility: suppose a significant portion of your load didn't support cookies? Or,
>if you were using URL rewriting for the sessions, suppose you forgot to use
>"response.encodeURL()"? In both cases the result is the same:
>
> Sessions are being created for a client, but the client won't remember his special
>"session id". This means a new session is created for this client with every request
>he makes!
>
> So, I have three questions I need to know:
>
> 1.) What kind of load is Tomcat experiencing on your machine, and where is this
>load coming from?
>
> 2.) Does your load support cookies? Is the "session id" being remembered by the
>client?
>
> 3.) How are you closing your sessions?
>
> Suppose each of your sessions weighed in at 512 bytes. If your load, at, let's
>pretend 10/hits second, didn't support cookies, you're going to need ~15mb to hold on
>to 30 minutes of sessions before they start expiring. This is because each hit is
>going to create a new session.
>
> Tomcat User please correct any mistakes I may have made here!
>
>
> Julius Davies, Programmer, CUCBC
> Email: [EMAIL PROTECTED], Ph: 604.730.6385
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, December 02, 2002 1:24 PM
> > To: Tomcat Users List
> > Subject: Re: Memory/Performance
> >
> >
> > Thanks for your comments. Well all my jspcode is definitely
> > session happy
> > and I am creating several
> > objects per session. The objects I am creating consist of mostly
> > string, int and floats, probably up to like 20 of each.
> > Although i create
> > a large application pool of jdbc
> > connections I am fairly positive that this is not the problem
> > because I
> > use this pooling model in several applications that don't
> > seem to have a
> > problem. I realize that every time a session is created all
> > these objects
> > must be allocated, and that should cause the memory blob to
> > keep growing
> > as the session count increase but I would think the memory stamp would
> > correspondingly shrink when all these sessions are closed and it
> > doesn't. I am basing this on tomcats crashing or slow behavior
> > in conjunction with monitoring the processes and memory
> > usage. What other
> > information can I share that would help? Like I said I don't
> > know if this
> > is tomcat or me or a bit a both so I am jsut throwing out
> > what seems to be
> > going on and looking for insight?
> >
> >
> >
> >
> > On Mon, 2 Dec 2002, Michael Nicholson wrote:
> >
> > > I suppose it depends on what you're doing, which,
> > unfortunately, I don't
> > > know.
> > >
> > > If you're overly filling your session w/ objects, or if you
> > have a session
> > > scoped bean that is spiraling out of control or something,
> > that might lead
> > > to the problem, or if you create/leave open jdbc
> > connections or stuff like
> > > that. I'm running tomcat 4.03 on a much less beefy system,
> > and I don't ever
> > > notice any memory issues, now that I make sure I close and null my
> > > connections and such.
> > >
> > > More info on what's happening might help, though..
> > >
> > >
> > > ----- Original Message -----
> > > From: <[EMAIL PROTECTED]>
> > > To: "Tomcat Users List" <[EMAIL PROTECTED]>
> > > Sent: Monday, December 02, 2002 3:51 PM
> > > Subject: Memory/Performance
> > >
> > >
> > > > I find that tomcat's memory stamp grows continually until
> > eventually there
> > > > are out of memory errors or it just bogs down. I am
> > running on jdk1.4_1,
> > > > tomcat 4.1.12, apache 1.27, mod_jk on the linux 2.2
> > kernel. The box I am
> > > > operating on has 1gig of memory and has dual gigahertz
> > processors. I
> > > > believe that tomcat has some serious memory leaks and/or
> > I am not writing
> > > > my jsppages properly. So i would like to ask two questions:
> > > >
> > > >
> > > > 1)Assuming tomcat has memory issues what can I do to control them?
> > > >
> > > >
> > > >
> > > >
> > > > 2)What techniques would you suggest to write jsppages
> > that help keep
> > > > memory consumption down? Are there ways to write
> > jsppages that makes them
> > > > more "garbage collection friendly"?
> > > >
> > > > please comment....
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
