SAWMILLFORUM

Eventually, when 7.2 calms down, we will have a true beta. That won't be as stable as 7.1 is now, but it will be more stable than 7.2 is now. We'll send mail to the newsletter if the beta goes public.

You're not alone in your "one bug after another" problems with 7.1.x. We've had a hard time of it with 7.1.x--we're not adding anything new to the branch other than bug fixes, which should make it more and more stable, and that is happening overall, but we've had a number of cases where one bug fix breaks something else, and our QA scripts don't catch it. We do pretty extensive manual QA, but it hasn't been testing these very well either, so we've really beefed up our automated QA suite lately (in the past couple months), bringing it up from less than ten "sanity check" tests (rebuild a database and check the Overview numbers; rebuild/update/expire and check the Overview; export a couple reports as CSV and check the numbers) to more than 130 tests in the current suite, which build databases using both "internal" and "MySQL", using several type of log data in several charsets, and perform and validate CVS and HTML exports of dozens of reports, with simple filters, date filters, and regular expression filters. 7.1.11, which is about to go out the door, passes all these tests. It took us a couple days of debugging just now to fix a few issues the newest tests turned up, so they are definitely helping. 7.1.11 also had a particularly complete manual QA test (humans at web browsers, trying to break it). I think 7.1.10 was pretty good (it was the first one to really benefit from the new huge test suite), and 7.1.11 will be better.

So we've done a lot lately to address stability problems with 7.1, and we'll keep working to make it as bug free as possible.

Thanks for the update on this, I appreciate it. Is there a rough limit on how big the database can be before you start running out of memory to do sessions. We've reduced the database from 250G to 24G so far, but it still stalls.

Are there any database or filters we can set to drop information to help it? Maybe drop individual IPs so it just works on /24's, or something else along those lines. They mostly just use it for reporting to the board, so I think if I can reduce the detail it will still be effective enough.

I'm trying to find out how to drop fields, I can't seem to do it through the interface however. Do I just have to modify the jessops.cfg and attempt to strip out all references to the referrer, or am I missing something easier?

1. Edit the .cfg file
2. Delete the database field
3. Delete any report that references it (there will often be two, one top-level report and one in Single-page summary).
4. Delete the report_menu item that references the report you deleted
5. Delete the cross_reference_group for the field

It is in fact possible to do a session analysis of a 24G database, just not the *whole* database. If you filter first, then the session analysis is done only for the filter set. For instance, if you have a 365GB database which covers a year, and you zoom on one day, then you're really only looking at 1GB worth of data. Do a session analysis on that, and it should work. Remove the filter, and you'll need several hundred GB of RAM to do that analysis....

If you do need a full analysis, then what you're discussing is just the way to proceed--you need to prune your data, using log filters. Drop most IPs if you can; delete references to sites or folders or anything else that you don't care about.