1. You should absolutely optimize it from time to time, but I don't know how much server power that'll save you. Take a look at your tables and see how big they are. Especially hitlog and sessions. You can empty those ( and basedomains and useragents ) without adverse affect other than requiring a fresh login and reduce some server load by the way.

2. Technically this will help but you have to ask yourself how much server power it takes to generate a post versus the rest of the page. I'm only guessing, but I think the posts are small compared to what you may have going on in the rest of the page. Sidebars and such.

3. There are settings you can control this stuff with. I don't know where off-hand, but a number of days to keep the hitlog active for. Set it to "1" and you'll keep some tables from growing to huge proportions. Also there are checkboxes for logging all hits on all public pages and all hits on admin pages. Uncheck them both and obviously hit logging pretty much goes away. Still set the other setting to "1" days worth because I think that affects your sessions. MAYBE NOT. In fact, probably not, but it can't hurt to try...

4. All counters count different things. Period. Anything that requires javascript will absolutely count less than anything that doesn't because not everyone enables javascript. b2evolution looks at page generation, which will have it's own set of flaws - of course. Because all counters count different things, all counters will have their own pluses and minuses.

I believe the "who's online" widget gives credit for being online up to 5 minutes after someone leaves ... but doesn't count them again if they come back. So ditch the "who's online" widget and see if your cpu usage goes down. That'll tell you if it is a measurable component of your overall server load yah?

This assumes you have the ability to see and track server load of course!

NoNumber. What's a "hot link"? In general, if a visitor can see it then so can a search engine, so all you would be doing is changing the path. Unless you mean a javascript-generated link. If that is the case then eventually the search engines will forget you entirely because I'm pretty sure they don't do javascript and therefore will not see anything to index.

5. How often do you post, and how many bloggers do you have? Frequently changing "first post" blogs won't benefit much from it, but if you post only occasionally - and especially if you are your only blogger - then you might consider generating a static page each time you post. What that does is nail a snapshot of your blog's entry page and provide an html equivalent. Thus the php execution to make the page is removed for anyone visiting only the main multi-post page. I've never done it so I don't know jack about how it actually works though.

5. Lose some sidebar stuff. I've no idea how much you use, but ask yourself if it is REALLY what you want on your sidebar. If not ditch it. EVERYTHING in the sidebar takes server power to generate, so lose what you thought "hooray" about but now might think "not worth the power it takes".

5. Build your skin to have either no sidebar on single post pages, or, to have a radically scaled down sidebar on single post pages. Evopress has no sidebar, so there is an example of doing that. Alternatively you could make a single post page include "Sidebar Single" container, then add only a couple of widgets to that container. This would be particularly helpful in situations where you use the "read more" feature because anyone reading more will currently get the full whammy again, but could be served a "low calorie" version. Commenters are obviously clicking through, so you'll save some cycles on page loads prior to commenting.

5. Write total crap. One of the best ways to save your server is to post stuff no one wants to read. Eventually even the search engines will get tired of crawling you because - if your posts suck enough - they'll just give up in disgust. This is the way I keep my traffic low. Works great!

1) I did the database optimization - I guess with all of the other changes, I won't know for sure if this helped.

2) I just saw where I could turn off the hit log and where you can autoprune. I kept it up for now... want to see how the numbers compare before and after my changes. But it is good to know I can just turn it off without a hack.

3) I have two sidebars, but have been slowly replacing widgets with the free html code widget (I am finding that most of the problems involve the php scripts).

4) There are several bloggers on my website and more importantly alot of member who post comments. An average day will see 5-10 posts and 100-200 comments. Creating static pages isn't probably a good idea.

5) After moving my blog to a folder and creating a static html root index page with hot links I have noticed my "who's on widget" is showing drastically lower numbers of "guest users" - this morning when I came on I had several member users, but only 1 guest. At times in recent days that was registering 200+ guest users - I am guessing that they were some sort of bot that was crawling my root directory and opening up pages. I have also seen a large decrease in my hitlog stats - as in perhaps as much dropping by 70% or so short term.

Moving the blog to a folder was just a hunch - but It may end up being one of the main controllable issues for me.

6) I think there is already alot of crap written on my blog - but for whatever reasons it is what keeps people coming back? I wonder out loud, however, if B2Evolution has limits to how big of a blog you can run? Being a political/election projection blog I will likely end up with 10,000 + visiters a day in late October and early November. At least those were the numbers I saw in 2004. I hope the software and server can handle it.

Set up a cron job to make a static page out of the front page.

Good luck

Does the size of the database for the blog matter at all in any of this?

My current blog has over 5000 posts in the archives and lord knows how many comments attached to those 5000+ posts. I know the page only brings up 6 posts, but does it use up "CPU" time running through the database to get the last 6?

5) moving your blog to a sub-folder has merely confused the poor bots for now, they'll soon catch up with the new location and start using the same amount of resources. Adding a robots.txt that excludes the sub-folder will keep the nice ones out, but you won't get as many search hits

6) EdB may like to delude himself that he writes the crappest content out there but, for all his gnarled fingers and grey hair ( before he shaved it all off so he didn't lose an eyeball whilst driving the cool car that's currently in the garage trying to be fixed before the warranty runs out ), I have him beaten hollow! NOBODY writes crapper content than me, and I have the stats to prove it :|

¥

coldhart wrote:

Does the size of the database for the blog matter at all in any of this?

Yes - of course it does. Look every app that uses a database has to LOOK at the database to do it's thing, and the more that's in it the more the app has to do to take that look.

Here's something that it's probably too late to do without working extra hard: create a second installation for older stuff, possibly by picking a cutoff date based on an election the repugnicans already stole, and in that database hold all the posts about that election cycle. That way the new and current content would have noticably less posts (and comments of course) to think about while generating pages. ... Actually maybe it wouldn't be so hard after all ...

Copy everything as-is right now over to a new database and path - possibly "archives" for example, or better still "pre-08 elections" given that you may want to do this each election cycle. Anyway once copied and given a fresh conf/_basic_config.php file simply go into that new installation's admin area and delete all the posts that relate to stuff about the here and now. After that you go into the current database and delete all the stuff that you did not delete from the "archives" database.

It would take time to do given that you would be deleting via the back office, but a courageous person could try to figure out all the tables that need to be edited and somehow work up a command or three (or six if you want to split hairs) to use in phpmyadmin to get all the posts & comments deleted that need to be deleted to keep things right. Hint: it's a lot more than just the evo_items__item table.

--------------

Hey do you have and use the "video" plugin? If so it is probably checked on every post whether you have a video or not. So there is another place to save a server cycle: uncheck it on posts that don't need it. Same applies to ALL renderer plugins that you don't use in any given post: if it is an "opt out" type of renderer then uncheck it when you don't need it.

That might not be too bad - I actually seperate alot of the content as it is by running several blogs -

I already created new blogs for the 2008 elections and have started to move my other frontline posters to individual blogs (rather than one community blog) -

I could effectively copy the old database (I assume through phpMyadmin?) and create a new install of that for my archives (deleting the new blogs I just created and leaving the old ones) - Then deleting the old blogs on the new install and leaving the new ones (I assume you can still delete a blog and all of the contents at once).

The only blog that would need to be split is my own. I could basically create new categories - move my old categories to one of the old blogs I would be deleting and presto chango, I would have a version of only new content.

Or... since the only two blogs hitting the main page that have any real long history is mine and the community blog, I suppose I could move some of those older posts to another dummy blog (that is not rolled into the main page) so they are not included when the main page is called. I wonder out loud how much that would help the resource issue?

Perhaps I would be best off arranging it all so that all of my older posts are in two or three blogs so that when I copy and reinstall - all I would have to do is delete the blogs I don't want for each version rather than mess around with deleting individual posts.

Make sure to move them to a new database, although thinking about that it might not matter given that the code will point to the proper tables - not just "any and all" tables in a database. I think. For me I would point to a completely new database just to be sure.

Also I'm not sure if deleting a blog deletes the contents of the blog. I seem to recall at some time in the past where deleting simply moved content to the next lower category number? That may have been when deleting a category though, so yeah maybe deleting an entire blog is the easy way to go. Heck if it works that way then move cats of obsolete posts over to the blog you're going to remove and then remove it. YAY!

Yeah through phpmyadmin would be the way. It's one of the options when you choose ... OPERATIONS I believe.

I created an Archive blog (that is not part of the main page call) and my main page now reflects 200 pages of 8 posts per page (or about 1600) rather than the 850 or so pages it showed before.

http://coldheartedtruth.com/politics/index.php

I have a 2.4.1 testing blog install - I can test the deletion of a blog there.

I also uninstalled the video plugin as I found it didn't work for me anyways. Just easier to copy and paste the u-tube code right in there.