Recent Topics

1 Apr 26, 2013 14:39    

Version 4.1.6

I'm not happy with the large sessions files in the database and I'm thinking of adding a script button which will delete anonymous sessions and leave only recognised users.

Any comments would be appreciated
Probably put the button on the Users > Sessions page in the backoffice

DELETE FROM `evo_sessions` WHERE `sess_user_ID`IS NULL

Thanks

2 May 19, 2013 14:15

I think this would be great. I don't understand what's changed in B2evolution over the years, but this table is huge every week when I do a back up and I have to manually clear it through myphpadmin. I went years with my blog backup being around 2-3 megs, now it's around 25 megs weekly. After clearing the sessions table it's aourn 1 meg.

I think the hack you describe would be useful, just wondering why b2evolution can't do something about this in their code.

3 May 19, 2013 20:13

My blog has ten thousands of hits every day, so my sessions table grow over GIG's not MB's..
It's also annoying for me how large sessions & hitlog tables are.. It still doesnt make sense to me why they grow that big; ie. they dont seem to store that much of data.

4 May 19, 2013 23:11

Thanks for your support, but I'm off the beaten track for a while.

5 May 19, 2013 23:14

So you guys all know that b2evolution does automatically prune the hits & session tables every tay and that you can configure the number of days of logs to keep, right?

6 May 19, 2013 23:29

I only want to prune only the anon (google and others which make up the regular large majority)

7 May 20, 2013 00:23

@fplanque wrote earlier:

So you guys all know that b2evolution does automatically prune the hits & session tables every tay and that you can configure the number of days of logs to keep, right?

That scheduled task is not working for me for some reason.. I tried running it manually just today to see what would happen but the result was a disaster for me (:

The new window that pops up just kept hanging and knocked down the site. I tried to track it down for a bit but gave up shortly.

8 Jun 02, 2013 00:09

So you guys all know that b2evolution does automatically prune the hits & session tables every tay and that you can configure the number of days of logs to keep, right?

Yes - that would be great, but for the past 6 months this doesn't seem to be working. I have mine set not to log hits or sessions and to prune daily. I had over 35 megs of data in the sessions table after 1 week. I've tried other settings, trying to use the scheduled job function, and even tried manually cleaning this through B2 - nothing is working other than going into myphpadmin and doing a manual purge weekly.

Can anyone explain why these functions are not working? If I'm telling the software not to log hits/session why does it keep doing this? Really - any help here would be appreciated as I'm finding my database is growing 10-20 megs larger each week when I do manual purges.

9 Jun 02, 2013 18:20

That's because b2evo uses DELETE queries which are super slow. On a busy production website I would just TRUNCATE sessions, hitlog and basedomain tables.

10 Jun 06, 2013 13:29

So by truncate you mean manually empty? Is there something that can be done automatically so that I don't have to keep going into the database tables manually? I can't seem to find any setting(s) that allow an automatic dump after a set period of time.

11 Jun 09, 2013 13:08

So by truncate you mean manually empty? Is there something that can be done automatically so that I don't have to keep going into the database tables manually? I can't seem to find any setting(s) that allow an automatic dump after a set period of time.

12 Jun 09, 2013 13:10

That scheduled task is not working for me for some reason.. I tried running it manually just today to see what would happen but the result was a disaster for me (:

The new window that pops up just kept hanging and knocked down the site. I tried to track it down for a bit but gave up shortly.

The pruning is working but NOT for sessions - anyone???

13 Jul 21, 2013 21:45

About 2 weeks ago I noticed B2Evo running slower and slower - often giving error pages because pages wouldn't post even after 30-60 seconds sometimes. Last week my webhost shut down php for an hour on my site because I was getting so many hits/crawls on my blog from China that it was pooching the whole shared server.

I then looked more closely at my web hits through google analytics, and my visits from China had been gorwing from 10 per week to 70 per day over the past few months. All of the Chinese visits were hitting various pages on my B2Evo blog. I now believe this was (at least for me) the source of the growing session files in my database table as well (see below).

To stop the madness I added the following code to the .thaccess file in the my main install folder of B2Evo...

RewriteEngine on
RewriteCond %{HTTP:Accept-Language} (zh) [NC]
RewriteRule .* http://mysiteserropage.html [R,L]

This effectively sent anyone hitting my site with a Chinese browser to a dead ended error page. My site went back to running properly within 30 seconds. Over the past week I have had 1 hit from a Chinese IP. When I did a database backup for the past week my file was about 2 megs total - WITHOUT any manual purge through myphpadmin of the sessions files. For the past several months weekly backups were hitting 50 megs.

So it seems for me by stopping any Chinese browsers on my blog (my blog is intended for US visitors only), everything went back to how it used to be about 6 months ago. I didn't exclude Chinese browsers from my main site where I serve only html pages, and there has been no corresponding jump in traffic on that portion of my website. I would suspect there are some hacking attempts at the B2EVo script from China. I would be interested to see whether others unhappy with the growing sessions files are perhaps seeing increased Chinese traffic....

15 Dec 25, 2013 05:13

@fplanque wrote earlier:

So you guys all know that b2evolution does automatically prune the hits & session tables every tay and that you can configure the number of days of logs to keep, right?

In theory, yes, but in practice, you have to manually truncate and optimize the tables because the automatic pruning doesn't do much for the huge tables.

16 Dec 26, 2013 05:15

In theory, yes, but in practice, you have to manually truncate and optimize the tables because the automatic pruning doesn't do much for the huge tables.

Could you give us some examples? This scheduled job is intended to manage any size of tables.

Thanks.


Form is loading...