HttpSession/HttpRequest and performance

[Frank Sikuluzu]

Session eats memory and most servers have the swapping featur that swap the session from memory to disk, this will cause performance slowdown. Thus, I am hesitating if I should use "session" to or "request" to store and carry objects over pages. If I use "request" I will use hidden variables to carry all the objects over pages so it is more burdensome for programming. But if the objects stored in "request" will never be swapped to disk, then using "request.setAttribute" and hidden variable can gain performance advantage. Do I make sense here ?

[Tim Baker]

I understand what you are saying.

Another issue to consider is that anything you keep in hidden fields on the page can be altered by an end user, so anything you get back from hidden fields should not be trusted.

The tidier solutions is definately to keep it on the session.

It's just a decision you have to make, if you design a very high load application then you may want to go for the solution that uses least memory. If it is not a high load application I would definately put it on the session to maintain readability and maintainability of your code.

Another option you didn't mention is URL rewritting. So each variable you have you encode into the URL, and all of the links you write on your page add the current values of the variables into the URLs. eg
<a href='index.jsp?var1=blah&var2=blah'>blah</a>
Then these are present in the same way that hidden fields would be on the request object. One problem with this approach is that bookmarks will launch with those variables set to values when the page was bookmarked, and also it suffers from the same problem as hidden fields, the results cannot be trusted.

[Sharad Agarwal]

We bounced around the same question recently. An excellent article discussing the pros and cons of the two approaches is here.

The short answer is that in most cases it is better to use the session object. Try to optimize what you do place in it. As another poster pointed out in a vert recent thread, ensure that entities placed in the session implement the serializable interface.

Another long thread to consider is this.
[ June 22, 2005: Message edited by: Sharad Agarwal ]

[Paul Bourdeaux]

If I'm not mistaken, URL rewriting still uses sessions. The difference between URL rewriting is that instead of storing the session ID on the client as a cookie, it is passed as part of the URL. The same resources are still being used by the container, so this would not solve the performance/memory issue.

On this same note, how many sessions is your web app supporting simultaneously? I suppose if you have a web app with a LOT of simultaneous use, or you don't have very much memory on your server, this might be a problem, but I have not seen any performance problems with the applications I support.

[Sharad Agarwal]

Originally posted by Paul Bourdeaux:
If I'm not mistaken, URL rewriting still uses sessions.

Depends on what you are rewriting into the URL. The expression usually refers to what you described - encoding the session ID into the URL. Tim was referring to a solution where you encoded all the session entities into the URL.

[Bear Bibeault]

Like Paul, I have never seen any performance or memory issues with the apps that I have written and support that make heavy use of sessions.

Saying that sessions cause memory problems is like saying that objects cause memory problems and should therefore be avoided. It depends on whether you are managing the resource properly or not.

Problems will result, of course, if you continually load up large or large numbers of objects into sessions and don't manage them. Just like other code, you need to be aware of how your resources are being utilized.

Succumbing to "premature optimization" by avoiding the use of sessions is unnecessary. Optimize when and if you run into performance problems, and then by intelligently managing the session data rather than by avoiding it.

[Ben Souther]

Depending on the nature of your app and it's usage, sessions can actually reduce memory consumption by reducing the number of objects that need to be re-created.

If your average user gets on the system for 15 minutes and performs an average of 25 operations that all require the construction of some object that could be re-used, then at the end of their session there is only one object sitting around waiting for garbage collection (GC) instead of 25.

As Bear said though, this, alone is not a reason to write your app this way.
Write it for clarity, profile it to see where the bottle necks are (if there is even a performance problem to begin with) and then look the areas where you can make the most improvement with the least disruption.

Often, it's not where you thought it would be.

[Frank Sikuluzu]

Originally posted by Tim Baker:
I understand what you are saying.

Another issue to consider is that anything you keep in hidden fields on the page can be altered by an end user, so anything you get back from hidden fields should not be trusted.

.

Want to know how end user can modify the hidden variables. I thought the page is on the server. Could you describe some details ?

thanks.

[Tim Baker]

When you create a page, you are creating HTML and sending it to the users browser. Hidden fields make up part of that HTML.

The user then hits submit and your form is submitted. All of the details in the page are analysed by the browser and the browser sends all of this information to your server. The hidden fields are included in this data.

You are sending data out to the user and then they are sending it back. You cannot be sure what you send is what you get back. Most browsers don't allow you to edit hidden fields directly. However if the user really wants to they can edit the values themsleves, maybe using javascript, or some other sly means. I don't know exactly how they would do it because I would never want to do it myself.

Think of this analogy. Someone asks you for a form they need to fill in. You post them a normal form printed on paper. Somewhere on this form you write some details you will need to know when you get the form back. If they were clever, they could scan the image in, edit it, and print it out before filling it in properly and sending it to you. You will never know the difference unless you check it against the value you sent them.

[Bear Bibeault]

I don't know exactly how they would do it

Easy as pie:

View source

cut

paste into editor

make changes

write file

display in browser

submit

[Bear Bibeault]

Not that I've ever done anything like that....