[_ck_]

Looks great but frame is definitely not the way to do it

If the part on top is just html, copy the html into bbpress’s header.php and make sure you include the stylesheet.

If it’s being rendered by wordpress, just copy the final result (use the view selected source feature on Firefox, etc.)

Although I would not attempt what I am recommended unless you know html+css.

[_ck_]

@ms420 that’s not how they do it here,

you just post your contact info and then we close the thread.

[_ck_]

Bump to remind people with larger bbPress forums to always back up first.

bbPress’s routine to merge are badly designed (so are the recount functions).

And never use the move feature to just rename a forum, you risk losing all posts in the original forum.

[_ck_]

Might be a problem with magic quotes turned on.

Check your phpinfo to see.

[_ck_]

I know several sites have converted from simplepress over the years but I can’t find anyone who has published their conversion routine.

[_ck_]

Ah, yes all secondary attributes unfortunately have to be disallowed now via bbcode-lite because of the security issue. It’s a quick fix with that side effect.

The trade-off of bbcode-lite is speed, so for security things have to be disallowed instead of trying to parse for all options which would slow things down.

HTML tags are saved when a post is made and then they are done, so it’s fast. But bbcode has to be parsed each and every time a page is displayed, so speed is important.

I guess an advanced feature for a future version would be to convert the bbcode into permanently saved html after the user’s time to edit has passed (ie. an hour). But that kind of sophistication will have to wait.

[_ck_]

@RedBull, if you were previously using the option to enable images via bbcode-lite, make sure you uncomment the first line that enables them again (by re-installing the plugin as default you’ve disabled them).

[_ck_]

Very nice!

That’s the second great use of forums as images that I’ve seen.

(the other one is http://gallery.weddingbee.com/ )

[_ck_]

Unless performance is crippling slow, those users’ arguments are very valid.

bbPress’s ability to be customized and slipped into foreign environments is extremely attractive. It’s incredibly easy to customize without breaking the core like most other forums.

But look at WordPress – it’s popularity defies ALL logic. Without heavy duty caching it would collapse most large sites. Apachebench would DESTROY it without page caching (using 17 categories with 7500 users and 10k posts with 10k comments). Of course it’s the sheer number of available customizations that override the care about lack of performance.

[_ck_]

Oh come on, the average person who looks at a graph that says product B is slower than product A doesn’t know how to be critical about the testing methods. If they did, every other commercial you see on TV would be useless.

Making a benchmark is a learning process. I am certainly not critical of the effort, I think it’s great someone took the time to do it. All I am saying the concept can be improved and expanded.

Early on I wrote bb-benchmark to analyze how bbPress performs from the server-side. It can be very helpful. But as fancy as the analysis is, in the end something I wrote much later on that gives much simpler data is far more practical for real-world results (browser-timer).

AB could be considered the parallel of bb-benchmark. It has it’s usefulness.

But one day there will be something more real-world like browser-timer.

[_ck_]

Of course it will be good to have content caching added, I already commented on how plugins can do that and bbPress never got content caching because it was being re-invented every couple of years. The reality is now it’s a moot point, bbPress 0.9 and 1.0-1.1 will never have it internally. I doubt 1.2/2.0 will ever either, they will simply rely on WP plugins to do page caching.

But I’m also saying the effects of content caching will be less visible if the test was more realistic to how forums are really used.

Apachebench is not complete enough and not real-world enough.

The problem is it’s going to take a week or two of coding to write something better and I can’t imagine someone doing that unless they were serious and skilled enough to do it.

I could write a plugin that defeats apachebench entirely, it’s very easy. AB does not load any content on the page, no images, no scripts. So basically all I have to do is send it one hard coded script tag, nothing else on the page, and the script loads the page. Then bbPress would rank as fast as an empty static html/php page.

That’s an extreme unrealistic example but it’s part of what I am saying. A real world test would load the page like a browser does, it would accept and return cookies so a user couple be logged in, and it would post new content between reads.

Writing a test like that is hard work, so I am not surprised that just using AB is the fallback.

You want bbPress to be cached? It can already do that, deep integrate with WP and then use wp-super-cache (or similar).

But then the page generation time is hidden in the first page render, let’s say it takes 800ms or more. Each next page will only take 20ms or less to serve. But Apachebench is “dumb” and doesn’t know that, it can only show best/worst and averages.

What if SMF or one of the others take 2 seconds for the first render on a new login and then 20ms for each successive? That 2 seconds is important if the content/user is constantly changing. What if a forum generates a list of topics the same for everyone but then uses javascript to change the list after the fact by using extra queries outside of the original page render? Apachebench cannot “catch” any of those scenarios or show their performance.

[_ck_]

Given this is my second most popular plugin, I’d like to make this sticky for 24 hours or more – if the other mods will please tolerate because of the severity.

[_ck_]

Okay here’s the reality.

Basically bbPress doesn’t run it’s tag filter on post_text when the text is finally displayed, because it would be too slow.

Instead it only checks tags during saving time and filters then.

If an item is not a tag AT SAVE TIME it won’t get checked.

That is how this is slipping through, because bbcode are not html tags.

I have a quick, dirty fix.

Basically anything that gets stuck INSIDE a tag ie. [HERE] = < HERE > is no longer allowed to contain spaces, single quote or double quote. Stuff [blah]HERE[/blah] = <blah>HERE</blah> is okay.

Preventing spaces alone, in theory, should be enough. Even url or entity encoding won’t get properly parsed. It will simply display as plain text and then you can see who is posting what instead of hidden stuff.

The only good news is that this problem in theory should not allow admin cookies to be stolen since the last version of 0.9 and 1.x already use HttpOnly cookies which cannot be read by javascript.

The downside of the quick-fix is that secondary attributes are no longer possible until I come up with another way. Example of secondary would be alt or title etc.

Many thanks for reporting this Tom!

[_ck_]

Double frack, it’s not just IMG.

Working hard on a fix.

All BBcode-lite users should upgrade to 1.0.5 IMMEDIATELY

(regardless if you allow images or not)

https://bbpress.org/plugins/topic/bbcode-lite/

https://plugins-svn.bbpress.org/bbcode-lite/trunk/

[_ck_]

Oh frack, it’s bbcode-lite.

I run through post-text so the bbpress parser never fires.

Fortunately img is disabled by default but I bet people turn it on.

Working on a fix.

[_ck_]

All your current benchmark proves is that bbPress will be slower for 20 concurrent connections over 1000 passes, where no-one is logged in and the content never changes.

What I am saying is that’s not how people run forums, you need a more realistic benchmark, which I know from experience is going to be tricky to code.

bbPress 0.9 will be faster than what you have shown by about 50% and then with content caching it will compete fairly against the others.

Apachebench is not dynamic enough to prove real-world usefulness and barebones bbpress out-of-the-box is certainly not setup for a large site. But with plugins it certainly can be. There are some reasonably large sites on the Top 100.

[_ck_]

None of my plugins (or any others) will be compatible with the next version of bbPress (1.2 or 2.0 or whatever they are going to call it to confuse people).

Also, none of the existing themes.

Basically think of the next version of bbPress as another program entirely that they just insist on calling bbPress anyway.

[_ck_]

Well I don’t want to discourage his initiative, it’s a great idea.

I just think a better tool then apachebench needs to be written.

Basically I’d want to see a simulated load with logged in users being served different content – ie. unread posts for different users

and most importantly, I’d want to see new posts generated (or existing posts edited) that force content caching to be defeated.

If bbPress 0.9 had been finished instead of all that all wasted coding energy Sam was forced into porting it to backpress, we’d definitely have some content caching by now.

But plugins can still do content caching themselves. For example I realized awhile back that the Hot Tag cloud that bbPress renders is taking at least 1/4th of the total page render time, and it does it each and every time, regardless if there are new tags added or deleted. So my Hot Tags Plus plugin caches the tag cloud as static html (as well as add many other features to it at the same time).

[_ck_]

quick ‘n’ dirty test: ab -c 20 -n 1000

bbpress 1.1

.             min  mean[+/-sd] median   max

Total:         46  458 117.9    453    1250

bbpress 0.9 (with $bb->load_options=true;)

.             min  mean[+/-sd] median   max

Total:         46  275  90.6    265     890

453ms vs 265ms (or 458 vs 275)

So, I’d expect I’d see around a 50% improvement on your box on 0.9

now – vs static cache content simulation:

bbPress 0.9 front page html saved as static.php

and <?php $test=1; ?> put at top to force PHP parser to turn on

.             min  mean[+/-sd] median   max

Total:         15   75  14.3     78     109

So 265ms vs 78ms

bbPress 0.9 is “only” 187ms slower than statically served PHP.

In a nutshell:

.             min  mean[+/-sd] median   max

bbpress 1.0:   46  458 117.9    453    1250

bbpress 0.9:   46  275  90.6    265     890

static PHP     15   75  14.3     78     109

[_ck_]

Actually the PHP version kinda proved my point about content caching.

It’s taking 3-4 ms.

The front page index on most of those forums is taking 20-25ms

That’s impossibly fast, it definitely means content is not being regenerated. If the cache was defeated it would have to re-render the whole thing and the page time would be significantly higher.

bbPress doesn’t even save the tag cloud between pages, it will re-render it each and every time, which is at least 1/4th of the page render time (that can be changed via a plugin).

So you aren’t testing renderer-vs-renderer, you’re testing content caching vs content caching. You aren’t even testing for logged-in users but only outside visitors.

If we are going to play that game, all someone has to do is port wp-super-cache to bbpress and it will beat every forum in existence, because static html will be served via htaccess directly and bypass PHP/MySQL entirely. So you’d be down to 4ms (or less) per page.

In any case, I am looking forward to seeing how 0.9 does against 1.0 under 20 concurrency.

[_ck_]

When you test a static file, I’d like to see it done like this.

1. run it as php so it has to go through the php parser

2. call it with a unique query on the url for each page per thread

the purpose of the above is to (slightly) defeat pure caching on apache’s part

I will always disagree that forums are write-once/read-many-times

That behavior is found with blogs, not forums.

The popular forums I belong to have new posts every few seconds which is very different than even the most popular blogs I read.

[_ck_]

Note the bb-config.php adjustment is for 0.9, it will have no effect on 1.x

[_ck_]

I look forward to a static page for comparison on your graph.

It will prove what I am saying about content caching.

I have a test SMF install handy and I can see it uses less than a half-dozen queries on a 2nd page load which is a dead giveaway there is caching – I am sure every other 3rd gen forum package has it too. You have APC running and I know that SMF also takes advantage of that, so probably do others.

bbPress never got content caching because Matt keeps having the core re-invented every couple years (backpress and now as WP plugin) so we keep getting back to square one for advanced features. Don’t be confused by versions 0.9 is a different program than 1.0 and 1.2 is a completely different program than 1.0 or 0.9 (that’s Matt’s fault).

So I still insist this isn’t a fair comparison.

But bbPress 0.9 should be about halfway between the 1.x and other forum software (ie. 50% faster) 0.9 will be continued to developed independently, so it’s worth benchmarking.

If you are willing to put a couple of tweaks in the bb-config with 0.9 I think we can get a little closer to the rest of the pack at the bottom, ie.

$bb->load_options = true;

off the top of my head (note that does nothing in 1.0)

[_ck_]

Didn’t it dawn on you when you see all the boards performing exactly the same under load with static content that they are using a page cache?

I mean that leaps out at me when I look at this:

http://bb-bench.com/benchmark/1/graphs/p/forum-middle.png

That’s obviously dynamic vs static content.

Put a static HTML page on your server and run the same tests against it to show the baseline.

[_ck_]

I already know from my own benchmarks that 0.9 in many cases is 50% faster than 1.x, if only because it loads 50% less code, not to mention fewer queries out of the box.

But as nice of an ideas as it is, your benchmark really cannot compare apples to apples.

ALL the other forums you have listed already use a page cache, in part or whole, which is why they have such high numbers.

What your benchmark should do is attempt to DEFEAT any page caching the forum is doing by generating new posts BEFORE every page load.

ie. POST / READ / POST / READ / POST / READ / POST / READ

The next version of bbPress will very much need a page cache just like most buddypress sites desperately need as they are very sluggish (because of the WordPress core).

A few people have successfully deep integrated bbpress with wordpress and then used an exisiting wordpress page cache. That would give similar numbers to what you have posted for other forums.