| Author |
 Topic  |
|
work mule
Senior Member
USA
1358 Posts |
 Posted - 16 October 2002 : 00:49:24
|
Has anyone bothered checking out their forum variables page in the admin section? Most likely not...
Cruise into at least one forum and then head on over to your admin area and take a look.
Look for -> _JumpBox
This is the rendered HTML for part of the Jump Box.
Now for some of you, this isn't going to be very large. When I saw mine, I thought it was an error at first. I pulled mine into TextPad and in ANSI, it's about 50K (400 forums). IIS stores this stuff as Unicode which requires 2 bytes per character. This would mean 100+K!! IN A SESSION VARIABLE!!! 
Now I know this was done with good intentions, but it's just a bad, bad thing. A very bad, bad thing. Regardless of the number of forums, this just isn't the sort of thing which should be stored in a session variable.
In the past I had done a mod which stored the Jump Box as arrays in an Application Variable. I can look at revisiting this. Actually I have to since this just isn't going to work. I'm not sure I'd do it the same as I did before. There were things I didn't know back then.
Worst case, I think I'd trade off the overhead of one more database query and store the rendered HTML in a text field. MEMBER_ID, JUMPBOXHTML.
A final option would be to either limit the list to the forum section pages and categories or just completely turn that off. I wonder how many actually use that anyways.
Anyone have any suggestions before I work on this? |
|
|
RichardKinser
Snitz Forums Admin
USA
16655 Posts |
Posted - 16 October 2002 : 01:23:37
|
work on what? There is nothing wrong with the way it is now. Just because you say "it's just a bad, bad thing. A very bad, bad thing." does not make it so.
If you want to change the way it functions on your own personal forum, go right ahead. |
 |
|
|
GauravBhabu
Advanced Member
4288 Posts |
Posted - 16 October 2002 : 01:49:04
|
quote:
Regardless of the number of forums, this just isn't the sort of thing which should be stored in a session variable.
What other option will be better then the way it is now?
|
|
|
|
Deleted
deleted
4116 Posts |
Posted - 16 October 2002 : 01:55:49
|
FYI, this prevents hundreds of database queries and long code execution during a whole session. Having 400 hundred forums is not usual...
(Thinking loud) Alternatively it can be put in a table like the way active users work and query once in a page that uses Jump To...
|
 Stop the WAR! |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 16 October 2002 : 01:56:54
|
You honestly don't see any problems with storing the html for the Jump To box in the session object?
For example, here at Snitz Forums, someone who's not logged in, will have a Session Variable "_JUMPBOX" created and will look like this:
<option value="default.asp?CAT_ID=6">Announcements</option>
<option value="forum.asp?FORUM_ID=118"> Announcements: Security Related Bug Fixes</option>
<option value="forum.asp?FORUM_ID=20"> Announcements: Community</option>
<option value="forum.asp?FORUM_ID=18"> Announcements: New Releases</option>
<option value="default.asp?CAT_ID=2">A Testing Area</option>
<option value="forum.asp?FORUM_ID=1"> Testing Forums</option>
<option value="default.asp?CAT_ID=10">Help Groups for Snitz Forums 2000 Users</option>
<option value="forum.asp?FORUM_ID=111"> Help: General / Current Version (v3.4.xx)</option>
<option value="forum.asp?FORUM_ID=107"> Help: General / Previous versions</option>
<option value="forum.asp?FORUM_ID=2"> Help: Database: MS Access</option>
<option value="forum.asp?FORUM_ID=22"> Help: Database: MS SQL Server</option>
<option value="forum.asp?FORUM_ID=73"> Help: Database: MySql</option>
<option value="forum.asp?FORUM_ID=89"> Help: Mail Configuration</option>
<option value="forum.asp?FORUM_ID=94"> Help: MOD Implementation</option>
<option value="forum.asp?FORUM_ID=48"> Help: Authentication: NT</option>
<option value="forum.asp?FORUM_ID=34"> Help: General / Current Version (Old)</option>
<option value="default.asp?CAT_ID=4">Frequently Asked Questions</option>
<option value="forum.asp?FORUM_ID=55"> FAQ About This Site</option>
<option value="forum.asp?FORUM_ID=113"> HOW DO I FAQs</option>
<option value="forum.asp?FORUM_ID=108"> FAQs for Using Snitz with Access</option>
<option value="forum.asp?FORUM_ID=110"> FAQs for Using Snitz with mySQL</option>
<option value="forum.asp?FORUM_ID=109"> FAQs for Using Snitz with SQLServer</option>
<option value="forum.asp?FORUM_ID=8"> FAQ for Beginners to Snitz Forums</option>
<option value="forum.asp?FORUM_ID=29"> FAQ For Developers</option>
<option value="forum.asp?FORUM_ID=32"> FAQ for Webmasters</option>
<option value="forum.asp?FORUM_ID=31"> FAQ Addition Requests</option>
<option value="default.asp?CAT_ID=17">Snitz Forums 2000 MOD-Group</option>
<option value="forum.asp?FORUM_ID=95"> MOD Completed Add-Ons</option>
<option value="forum.asp?FORUM_ID=25"> MOD Add-On Forum (W/Code)</option>
<option value="forum.asp?FORUM_ID=26"> MOD Add-On Forum (W/O Code)</option>
<option value="default.asp?CAT_ID=5">Community Forums</option>
<option value="forum.asp?FORUM_ID=77"> Suggest forum.snitz.com Content</option>
<option value="forum.asp?FORUM_ID=7"> Show-Off Your Forums</option>
<option value="forum.asp?FORUM_ID=6"> Code Support: ASP (Non-Forum Related)</option>
<option value="forum.asp?FORUM_ID=120"> Code Support: ASP.NET (Non-Forum Related)</option>
<option value="forum.asp?FORUM_ID=9"> Community Discussions (All other subjects)</option>
<option value="forum.asp?FORUM_ID=87"> Graphics & Style in Snitz!</option>
<option value="default.asp?CAT_ID=15">Snitz Forums 2000 AWD-Group</option>
<option value="forum.asp?FORUM_ID=86"> AWD General Discussion</option>
<option value="default.asp?CAT_ID=14">Snitz Forums 2000 DOC-Group</option>
<option value="forum.asp?FORUM_ID=80"> DOC Discussion</option>
<option value="forum.asp?FORUM_ID=78"> DOC In-Box</option>
<option value="forum.asp?FORUM_ID=79"> DOC Out-Box</option>
<option value="default.asp?CAT_ID=1">Snitz Forums 2000 DEV-Group</option>
<option value="forum.asp?FORUM_ID=105"> DEV Internationalization (v4)</option>
<option value="forum.asp?FORUM_ID=117"> DEV Internationalization (v4-archive)</option>
<option value="forum.asp?FORUM_ID=17"> DEV Discussions (General)</option>
<option value="forum.asp?FORUM_ID=11"> DEV Bug Reports (Open)</option>
<option value="forum.asp?FORUM_ID=23"> DEV Discussions (Oracle)</option>
<option value="forum.asp?FORUM_ID=83"> DEV Discussions (VFP)</option>
<option value="forum.asp?FORUM_ID=58"> DEV Discussions (DB2)</option>
<option value="forum.asp?FORUM_ID=96"> DEV Bug Reports (Closed)</option>
Something that's not visible in the above are all the & nbsp; entities in each row. There's six separating the opening option tag and the name for every forum. Don't forget that each space, character and linebreak adds up.
For Snitz, the session variable would equals 6010 bytes (as ANSI) which actually is 12020 bytes (or 11.7 KB) because of how IIS Session Variables are stored.
Now multiply that by how many active sessions your forum might have at one time. Include the overheard of any additional Session Variables and Application Variables and it's no wonder that people might be getting complaints from their providers about resources consumed by the forum.
This is one point I seriously have to disagree with you on. By the time, the forum I'm working on is deployed, it will be whittled down and won't have as many forums as it does. However if it's even half of what it is, then for every user that hits the forums, then I'll be taking a 50K hit for a single session variable.
For large or heavy traffic websites, I'm sorry, but I just don't think the current method is the best option.
|
|
|
|
e3stone
Average Member
USA
885 Posts |
Posted - 16 October 2002 : 02:04:20
|
edit: The following message was a pure reaction-response. I might have taken a response the wrong way, but I've noticed these types of responses over the last few months. Just voicing my opinion and I know I'm not the only one who holds this opinion.
quote:
Originally posted by RichardKinser
work on what? There is nothing wrong with the way it is now. Just because you say "it's just a bad, bad thing. A very bad, bad thing." does not make it so.
If you want to change the way it functions on your own personal forum, go right ahead.
WMII -
Don't you know that you're not suppose to ever imply that their is a design fault in Snitz?!? The way it is now is perfect and Snitz isn't going to change even if a site has a very busy forum, with 400+ forums, and 100 active users at a given point. The host's servers should be able to handle 10 mb of session information!! 
geezz...we all know this is your baby, but you don't have to respond the way you did, Richard. Take a lesson from GauravBhabu. His reply was what I would have expected from a developer or Admin. Sometimes I wonder. 
|
<-- Eric --> |
Edited by - e3stone on 16 October 2002 02:24:58 |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 16 October 2002 : 02:19:01
|
Take it easy on him Eric.
If the roles were switched, I'd probably say the same. 
I forgot to sprinkle in my light-hearted smilies when I wrote this part:
quote:
Now I know this was done with good intentions, but it's just a bad, bad thing. A very bad, bad thing. Regardless of the number of forums, this just isn't the sort of thing which should be stored in a session variable.
I had this song going through my head at the time --> "I did a bad, bad thing...". I got carried away. I apologize if you took me seriously.
All that aside...
For small sites, this probably works out great. Like bozden commented on, the Jump To is a nasty section of code when it's built. Queries and functions and all. Pre-rendering it is definitely a good thing to do. The bad thing is that it's not the same for everyone so you can't pre-render it once and use for everyone. It must be pre-rendered for each user.
I'm happy that they made this change from the older versions (one less mod to update from 3.1  ). I just disagree with where it's stored. Small site, low-mid traffic - session might be okay. Large site, heavy traffic - storing the pre-rendered html might be best stored in the database in a single field.
Also, consider how the storage required can be reduced by the following:
6010 bytes - original (unmodified)
5323 bytes - by removing the spaces used for indenting, the tab and the carriage return/linefeed
3775 bytes - by removing & nbsp; entity code.
For the latter, since this forces the indented look in the list, an option might be to store regular spaces and do a replace on the string, replacing a series of six regular spaces with six & nbsp; entities before sending to the user.
|
|
|
|
GauravBhabu
Advanced Member
4288 Posts |
Posted - 16 October 2002 : 02:23:43
|
quote:
...we all know this is your baby
I did not know that and I don't think any single person can claim so.
|
|
|
|
RichardKinser
Snitz Forums Admin
USA
16655 Posts |
Posted - 16 October 2002 : 02:23:47
|
| I really don't see the problem though. This site handles it just fine. Huw was actually the one who recommended that we do it this way. If he thought that this would be hell on the server, do you think he would have ever suggested it? Why is everyone so afraid to use Session Variables or Application Variables? We were trying to get away from accessing the database as much, this accomplishes that. Using a different table to store the same information would not. |
|
|
|
RichardKinser
Snitz Forums Admin
USA
16655 Posts |
Posted - 16 October 2002 : 02:25:07
|
quote:
Originally posted by GauravBhabu
quote:
...we all know this is your baby
I did not know that and I don't think any single person can claim so.
I don't remember ever claiming that.  |
|
|
|
e3stone
Average Member
USA
885 Posts |
Posted - 16 October 2002 : 02:37:06
|
I was being quite sarcastic. I realize that you never claimed that, but it tends to come across that way in some of your replies to people that say there's something wrong with forum code or asking why Snitz did this or that, or proposing a different way of doing something in the code. I not saying you're the only one that responds in this "tone;" however, it might just be the way I'm reading it. who knows.
Instead of replying with "it works, we're not going to change it. Change it yourself" why don't people respond with "what other ways would you suggest?" or something to that sort. |
<-- Eric --> |
|
|
|
ajhvdb
Junior Member
Netherlands
392 Posts |
Posted - 16 October 2002 : 03:19:48
|
| Storing this in a session var prevents calls to the DB on every page. So I guess is utilization against memory usage. In your example I would really suggest removing the Jumpto Box because utilization will increase. |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 16 October 2002 : 03:33:25
|
It's not like I started posting yesterday. 
This forum is a lot of work and it's amazing. I've learned a lot of my stuff from working through the forum code and reading the boards. In return I try to make suggestions where I can with the best intentions at heart, hoping that at least 10% of the time my posts make some sense. If we couldn't propose alternative methods, snitz might still be passing titles in the querystrings. |
|
|
|
HuwR
Forum Admin
United Kingdom
20595 Posts |
Posted - 16 October 2002 : 03:44:02
|
quote:
I was being quite sarcastic. I realize that you never claimed that, but it tends to come across that way in some of your replies to people that say there's something wrong with forum code or asking why Snitz did this or that, or proposing a
Maybe thats because he knows the code better than you do.
quote:
In the past I had done a mod which stored the Jump Box as arrays in an Application Variable.
Now, that would be really dumb, since not everybody has the same jumbox.
The resource and memory usage have gone DOWN since 3.4 was installed on this server, so none of your arguments really hold up. |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 16 October 2002 : 04:00:34
|
quote:
Originally posted by ajhvdb
Storing this in a session var prevents calls to the DB on every page. So I guess is utilization against memory usage. In your example I would really suggest removing the Jumpto Box because utilization will increase.
Removing it completely is an easy way out, but it is a valid option.
I thought that this used to be an option in the 3.1 version.
Anyways...I think there are a variety of options. It's just thinking through a couple of them and weighing the pros/cons. I could see a couple of different implementations. Ranging from the current method to having none at all.
A large site could keep a simplified version. Keep the generic stuff at the bottom of the list (Active Topics, FAQ, Member) and possibly include just the categories. This could be cached in a single Application Variable and referenced.
In regards to the db query, the connection is already open. Considering the number of queries already involved, what's one more simple query? Additional query vs. 100K block of memory/visitor. I look at it this way, the query is performed when needed - resources utilized and released upon completion, whereas that 100KB block persists until the session expires, which could be up to 20 minutes after the person last visited the site. If 50 people hit the page and leave after a couple of minutes - now I'm out 5,000KB (plus overhead) until their sessions expire. |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 16 October 2002 : 04:11:22
|
quote:
quote:
In the past I had done a mod which stored the Jump Box as arrays in an Application Variable.
Now, that would be really dumb, since not everybody has the same jumbox.
Hence why I said "I'm not sure I'd do it the same as I did before. There were things I didn't know back then.". I also later posted "The bad thing is that it's not the same for everyone so you can't pre-render it once and use for everyone. It must be pre-rendered for each user.".
quote:
The resource and memory usage have gone DOWN since 3.4 was installed on this server, so none of your arguments really hold up.
The 3.4 version is a major improvement, it's awesome. No one is going to argue that. That doesn't mean that improvements still can't be made. |
|
|
|
Topic |
|
Topic Locked
