Thread/Forum Read Marking Type

[Thomas P]

Hi Big Board Admins,

which Thread/Forum Read Marking Type do you use?

We recently upgraded to vB3.6 and are in the process of reviewing our options.

1) Inactivity/Cookie Based
Once a user has been inactive for a certain amount of time (the value of the cookie timeout option) all threads and forums are considered read. Individual threads are marked as read within a session via cookies. This option is how all versions of vBulletin before 3.5 functioned.

2) Database (no automatic forum marking)
This option uses the database to store thread and forum read times. This allows accurate read markers to be kept indefinitely. However, in order for a forum to be marked read when all threads are read, the user must view the list of threads for that forum. This option is more space and processor intensive than inactivity-based marking.

3) Database (automatic forum marking)
This option is the same as a previous option, but forums are automatically marked as read when the last new thread is read. This is the most usable option for end users, but most processor intensive.

And for how many days do you store the info (Database Read Marking Limit)?

How about your experiences regarding load and usability?

Thanks,
Tom

[Ted S]

These days more and more sites are suing #3 or #2 if resources are an issue. I personally prefer #3 myself but it's definitely more intensive than 2 and much more so than 1. However, as your site grows and people use other sites more, it2 or 3 seem to be a necessity to be competitive.

When implementing either of the db options expect to need more memory on your db server and potentially more issues related to corruption as your db is accessed more often.

Lastly, 10 days is my normal setting for #3.

[Thomas P]

Thanks for you expertise.

[Lynne]

I've always used option 1, so my users have never known anything different. But, on average, we probably only have 15 new pages of threads a day.

[Deriel]

I use option 1. The others are performance proibitive in my case... I tried them while ago and opted for 1. The users liked de the option 3, mas it is too resource intensive.

[osustw]

Ah, this is a timely thread for me. I've been thinking of making the change from #1 to either #2 or #3. Some people check our forum on their work machines, then go home and don't like having to wade through threads they've already read during the day (slackers!) and vice versa. So the database options seem to make sense.

I have a couple of worries. Ted, you mentioned possible db corruption issues. How common are problems related to this? If it were to get corrupted, would a simple 'fix' be to turn the option back to #1? And how much more intensive are the last two options on the server than the first one?

One last question. How do the server based options handle guest viewers? Do they just see all unread, all the time?

[Ted S]

Corruption is something your database can always and probably will experience regardless of your setting. Increasing the number of times the database is written to either by changing options or just having more traffic/ posting/ activities means more room for things to go bad. If you do end up getting corruption it tends to be minor (although many larger vb forums have had to deal with fairly serve corruption issues) but won't be fixed by turning anything off. If you want to fix a corrupt table you can start with the "check <table name>;" and "repair <table name>;" commands from your mySQL interface.

There's a few different schools of thought on this but I like to check my main tables on a very regular basis and run the myisamchk command (another way to run check without mysql being up) nightly... but that's just me.

As for how much more intensive the #2 and #3 options are. I don't have a benchmark but it's definitely a noticeable difference, especially if you go with #3.