Post caching planned ?

[Weppa333]

Unless I'm mistaken, there is no post caching (like in VB since 3.6 at least) in xenforo.

On my install, the SQL takes around 5% of the CPU time, the rest is INTENSE cpu processing due to posts not beeing cached, I guess. And I'm using Xcache !

My XF is roughly 2 times slower than my previous VB3.6 installation, with render times around 300ms for a 20 posts page. (150ms or less for the same page in vb3.6) I see the same times here too (a 20 posts page takes 250ms to compute, for a logged in user.)
Short story is ; it's way slower than older technology. It's a pity because the SQL part is much faster than vb3.6. The problem is, I think, the intense cpu computing on posts. Maybe the framework itself too... And this is on a dedicated dual 6 core opteron !

I read someone this was planned : is this still in everybody's minds ?

PS
Thanks for a great product - this is no criticism.

 

[Jeremy]

Do you have BBCode caching turned on?

 

[pegasus]

In my experience, uncompiled OOP tends to be slower and use more memory and CPU than uncompiled procedural code. This is simply due to the nature of OOP, which increases the number of file inclusions, objects, function/method calls, and recursion/execution depth. I feel like the major benefit that has driven anyone to continue using it personally, is that OOP doesn't really require coders to start at the "beginning" when coding something new, it makes it more organized, more reusable, and easier to modify in the future, whether to change something or add a whole new feature.

XenForo pages that don't contain posts tend to be much faster than comparable pages on vBulletin 4, and somewhat faster than on vBulletin 3. I suspect this is due to a more efficient design in general, where we don't have such large caches (forums, plugins, phrases, templates), we run fewer eval()s, and we don't have a global.php that tries to figure out what thread we're in when we're not even reading a thread.

About XenForo's BB-Code parser compared to say vBulletin 3.6. They are different animals completely. vBulletin 3.6 basically reads a post and parses each tag as it goes. XenForo basically does do the same thing, except that each new tag inside an open tag is parsed from within the method of the containing tag. This approach is more intuitive and eliminates some unexpected behaviors of vBulletin's parser, but as I mention with OOP in general, it introduces several more method calls per nested tag than vBulletin 3 did, and thus takes slightly more time to parse an individual tag.

A while back I created a 500,000 character post in both vBulletin and XenForo to benchmark their parsers with an extreme case. The post contained regular BB-Codes, custom BB-Codes, and broken BB-Codes. If I remember correctly vBulletin took about 19 seconds to parse the single post, but XenForo hit my 30 second PHP timeout. I tried lowering the size to 300,000 characters, but XenForo was still over time. I didn't really care enough to increase the timeout and see how long XenForo would take, I just set the Maximum Characters settings so that users wouldn't be able to make such insanely long posts.

I have found that some custom BB-Codes increase the parser time more than others, because they make more calls or they practice more recursion than normal. An example is the TABLE BB-Code you can find on here.

However, due to the other performance improvements XenForo has over vBulletin, you really shouldn't be able to notice these things unless your users make very long posts, use BB-Code excessively (there were no BB-Codes at all in this post), and your BB-Code cache is disabled.

 

[Weppa333]

Thanks for your analysis Pegasus.

The fact remains, even this board which is probably properly configured , render times are above 250ms for a 20 posts page. These are high render times, I've seen forums with render times of 10ms ( because they generate static HTML - something IPB was planning to but never did release, afaik ).

Every single page I can think of is faster in VB3.6 ( start thread, reply, show post, etc). I fully understand the reasons you're explaining Pegasus, but honnestly, I would like XF to over perform 15 years old technology !

Point taken that XF is somewhat faster than VB4 or 5, but I'm not sure VB4 is a quality benchmark

 

[Weppa333]

This page, at post #4, renders in 222ms for a non-admin logged in user (me).

Maybe XF could solve the entire "issue" by integrating more closely with a reverse proxy, or by having somekind of "worker agent" parsing posts, creating html copies, and have index.php route to static html copies whenever possible.

 

[digitalpoint]

Caching rendered posts definitely makes threads faster. I made an addon that we use on digitalpoint.com, and it more or less cuts page rendering time of thread pages in half. Before anyone asks, it's not really designed for use outside of digitalpoint.com... It makes a couple of assumptions that could cause issues with other sites... It only works if you have 1 style, 1 language and you don't have attachment permissions that vary for user groups (for example if you blocked guests from downloading/seeing attachments).

 

[Weppa333]

Well it seems we're the only ones that the current render times do bother
As a comparison, my facebook feed renders in 60ms.

Yes, we could "hide" XF behind Varnish or Litespeed ($$$) but , again, stock VB3.6 is two times faster than stock XF to render a page - I bet there is a way to make XF faster... More and more people consider HALF A SECOND of render time as "slow". So does google by the way. We're dangerously close to what's slow.

I discussed with IPB's devs and they planned to create what they called a "worker" than would render page both for the surfer and output them to disk/sql/memcache, and output these static pages in certain cases. Of course, it's still nowhere. But well, it's IPB after all

 

[wmtech]

I am almost sure Mike is thinking about such a cache for one of the future versions.

 

[Liam W]

Caching rendered posts definitely makes threads faster. I made an addon that we use on digitalpoint.com, and it more or less cuts page rendering time of thread pages in half. Before anyone asks, it's not really designed for use outside of digitalpoint.com... It makes a couple of assumptions that could cause issues with other sites... It only works if you have 1 style, 1 language and you don't have attachment permissions that vary for user groups (for example if you blocked guests from downloading/seeing attachments).

I'm asking... Could you release it (if only for DP Premium), so I can make it work for my forums?

 

[digitalpoint]

I was actually planning on doing it... one of these days when I have some time to wrap it up into something installable.