MyBB Community Forums

Full Version: Sticky Affecting Processing Time in Forumdisplay
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
(2021-02-25, 09:57 AM)Omar G. Wrote: [ -> ]
(2021-02-25, 12:09 AM)Laird Wrote: [ -> ]The most exciting was the control_object function

I bet you already have some crazy stuff to implement it on, huh?

I thought so at first! But that turned out to be a little premature. My immediate reaction was:

"Whoa, cool! This can save me a core edit for MyConversations! And that's the only one so far, so I can avoid the need for core edits entirely! Bazinga!

"I'm editing the file defining the PMDataHandler class so that I can modify that class with methods sympathetic to MyConversations rather than the core PM system, but control_object allows me to modify the class on-demand, without the need to edit its containing file!"

Sadly, that reaction was tempered by the later consideration that, no, unfortunately, I do not always get to intercept the code between the construction of the class and the calling of its methods, so that control_object cannot always fulfill my goal of replacing its methods with "sympathetic" methods, and the core edit is, after all, still necessary.

But I will certainly be on the lookout for other crazy stuff to implement it on!

(2021-02-25, 09:57 AM)Omar G. Wrote: [ -> ]xThreads made crazy stuff to my plugin ideas 🤪

I'm definitely gonna have to investigate this xThreads business! Where would you suggest I start?
(2021-02-25, 09:54 AM)Omar G. Wrote: [ -> ]Try the attached Hook instead. It is possible that you find additional issues with other plugins that you might need to fix on the way. I have, for example, some plugins which add data to the thread cache in a similar way to how xThreads does.

The previous attachment might work just fine in vanilla install, so I won't remove it.


Thanks gave that one a try, no error warnings but it seems to repeat normal threads twice. Normal threads replace stickies. So sticky threads dissapear and normal threads are in Important Threads and Normal Threads sections.

(2021-02-25, 10:34 AM)Laird Wrote: [ -> ]I'm definitely gonna have to investigate this xThreads business! Where would you suggest I start?

Download XThreads: http://mybbhacks.zingaburga.com/showthread.php?tid=288
Example Usages: http://mybbhacks.zingaburga.com/showthread.php?tid=559


Also recommend Template Conditionals and PHP in Templates for extra fun

Template Conditionals: http://mybbhacks.zingaburga.com/showthread.php?tid=464
PHP in Templates: http://mybbhacks.zingaburga.com/showthread.php?tid=260

Main reason I like experimenting with MyBB over other scripts is because of XThreads.
[Post majorly edited to remove pointless and overwrought silliness that was inappropriate and, frankly, embarrassing in hindsight]

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Download XThreads: http://mybbhacks.zingaburga.com/showthread.php?tid=288

Yep, thanks, I figured that out after reading that the GitHub version was not recommended.

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Example Usages: http://mybbhacks.zingaburga.com/showthread.php?tid=559

Thanks again. I've tried the first example with no success so far. Initially I made the foolish mistake of confusing "Custom Thread Fields" with "Custom Profile Fields", but after correcting that mistake, I still foundered on item #5 in the list: the new "Thread Description" text box simply doesn't show up. Anyhow, I will keep on trying, as well as try a few of the other examples and eventually figure this plugin out, because...

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Main reason I like experimenting with MyBB over other scripts is because of XThreads.

...this is high praise.

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Also recommend Template Conditionals and PHP in Templates for extra fun

Template Conditionals: http://mybbhacks.zingaburga.com/showthread.php?tid=464
PHP in Templates: http://mybbhacks.zingaburga.com/showthread.php?tid=260

Nice. I've seen other references to and recommendations of them too. They sound like quality goods, although it also seems that they might become redundant with 1.9's adoption of Twig.

P.S. Re this:

(2021-02-24, 11:25 PM)Laird Wrote: [ -> ]
(2021-02-24, 09:33 PM)Sharree Wrote: [ -> ]This seems to be caused by the "// Start Getting Threads" part in the forumdisplay.php file

Based on the query you shared, I don't think you've identified the right part of the code. The query in the code is different.

I apologise for charging you with making a mistake. I see now that the mistake was mine: I was simply confused by the edits to the query that XThreads seems to have been making behind the scenes. You were very polite not to point that out.

P.P.S. Did you give the indexes Matt and I suggested a go? If so, did they have any effect at all? I did try mine out on a MariaDB installation to make sure that they were actually used by the query planner, but I didn't test whether the MySQL query planner would similarly use them, nor whether, though at least used, they had any impact on performance. I've just now though tested out the performance gain on a mirror of a small-medium sized forum and unfortunately the performance gain seems to be minor - maybe, say, 15% - so I'm not exactly hopeful, but maybe on your forum the gain will be more marked. The first one seems to be preferred by the query planner.
(2021-02-25, 01:25 PM)Laird Wrote: [ -> ][Post majorly edited to remove pointless and overwrought silliness that was inappropriate and, frankly, embarrassing in hindsight]

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Download XThreads: http://mybbhacks.zingaburga.com/showthread.php?tid=288

Yep, thanks, I figured that out after reading that the GitHub version was not recommended.

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Example Usages: http://mybbhacks.zingaburga.com/showthread.php?tid=559

Thanks again. I've tried the first example with no success so far. Initially I made the foolish mistake of confusing "Custom Thread Fields" with "Custom Profile Fields", but after correcting that mistake, I still foundered on item #5 in the list: the new "Thread Description" text box simply doesn't show up. Anyhow, I will keep on trying, as well as try a few of the other examples and eventually figure this plugin out, because...

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Main reason I like experimenting with MyBB over other scripts is because of XThreads.

...this is high praise.

(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Also recommend Template Conditionals and PHP in Templates for extra fun

Template Conditionals: http://mybbhacks.zingaburga.com/showthread.php?tid=464
PHP in Templates: http://mybbhacks.zingaburga.com/showthread.php?tid=260

Nice. I've seen other references to and recommendations of them too. They sound like quality goods, although it also seems that they might become redundant with 1.9's adoption of Twig.

P.S. Re this:

(2021-02-24, 11:25 PM)Laird Wrote: [ -> ]
(2021-02-24, 09:33 PM)Sharree Wrote: [ -> ]This seems to be caused by the "// Start Getting Threads" part in the forumdisplay.php file

Based on the query you shared, I don't think you've identified the right part of the code. The query in the code is different.

I apologise for charging you with making a mistake. I see now that the mistake was mine: I was simply confused by the edits to the query that XThreads seems to have been making behind the scenes. You were very polite not to point that out.

P.P.S. Did you give the indexes Matt and I suggested a go? If so, did they have any effect at all? I did try mine out on a MariaDB installation to make sure that they were actually used by the query planner, but I didn't test whether the MySQL query planner would similarly use them, nor whether, though at least used, they had any impact on performance. I've just now though tested out the performance gain on a mirror of a small-medium sized forum and unfortunately the performance gain seems to be minor - maybe, say, 15% - so I'm not exactly hopeful, but maybe on your forum the gain will be more marked. The first one seems to be preferred by the query planner.

I was going to call you a d*uche earlier but you've edited your post. Thing is I don't know you or your programming history. You asked a question that I misunderstood and gave a response that's probably perceived as nooby at your level. I guess I'd be bothered too if I got development advice from someone and I've been programming before that person was born. + I'm a graphic/web designer only capable of writing HTML and CSS along with a few lines of PHP and SQL.



So Matt's post. I've already tried adding a index to the sticky column. I haven't tried your queries. I'm going to backup my table and give those a try now.

Oh wow Laird. Thanks so much. Adding those two indexes completely fixed it. Went from 3 seconds processing time down to 600ms. This is great, this issue has been bothering me for the last month.

I also have an infinite scroll replacing pagination so it use to take forever for the next page to load now it's nearly instant. Thanks again. I'm sure my users will have a better experience.
(2021-02-25, 10:28 PM)Sharree Wrote: [ -> ]I was going to call you a d*uche earlier

It would have been warranted. Please see my PM.

(2021-02-25, 10:28 PM)Sharree Wrote: [ -> ]Thing is I don't know you or your programming history. You asked a question that I misunderstood and gave a response that's probably perceived as nooby at your level. I guess I'd be bothered too if I got development advice from someone and I've been programming before that person was born. + I'm a graphic/web designer only capable of writing HTML and CSS along with a few lines of PHP and SQL.

That's very generous of you - too generous in fact: there was nothing wrong with your response. I just responded in turn like an utter jerk. Again, I apologise.

(2021-02-25, 10:28 PM)Sharree Wrote: [ -> ]So Matt's post. I've already tried adding a index to the sticky column. I haven't tried your queries. I'm going to backup my table and give those a try now.

OK. Will be interested to know how you go.

Incidentally, to you or Omar or anybody else, I wonder whether you can explain something:

On my local mirror of a small-medium forum, MariaDB seems to cache the results of the query we've been investigating in this thread. When I restart MariaDB (which is the only way I seem to be able to clear its query cache), the query (prior to Omar's splitting it in two, and prior to the indexes I've suggested we trial) takes roughly 140ms [ETA: to clarify, here I am running the query via the commandline mysql client]. After that, presumably due to the query being cached, it takes under 1ms.

I thought that I would be able to replicate these timings in the &debug=1 page for the corresponding forum page: that is, that if I restarted MariaDB and then immediately refreshed the debug page, I would see the query taking the 139ms it takes on its first run, prior to being cached - but I don't. I see it taking under 1ms, as though it were cached from the start.

I'm digging into the code to see if I can see a reason for this, but just thought I'd raise the question here and now in case anybody has an immediate answer.

(2021-02-25, 10:28 PM)Sharree Wrote: [ -> ]Oh wow Laird. Thanks so much. Adding those two indexes completely fixed it. Went from 3 seconds processing time down to 600ms. This is great, this issue has been bothering me for the last month.

I also have an infinite scroll replacing pagination so it use to take forever for the next page to load now it's nearly instant. Thanks again. I'm sure my users will have a better experience.

I'm very glad to hear that, and glad to have helped. Incidentally, you probably only need one of the indexes, and can drop the other, which would save database space (assuming space is an issue for you). I think that the debug page will tell you which one's actually being used; the other would then be redundant and could be dropped.
(2021-02-25, 12:27 PM)Sharree Wrote: [ -> ]Thanks gave that one a try, no error warnings but it seems to repeat normal threads twice. Normal threads replace stickies. So sticky threads dissapear and normal threads are in Important Threads and Normal Threads sections.

Hi, could you share a list of plugins you use? This is most likely due to conflicts with other plugins.

Quote:Oh wow Laird. Thanks so much. Adding those two indexes completely fixed it. Went from 3 seconds processing time down to 600ms. This is great, this issue has been bothering me for the last month.

So is this fixed for you?


(2021-02-25, 10:34 AM)Laird Wrote: [ -> ]Sadly, that reaction was tempered by the later consideration that, no, unfortunately, I do not always get to intercept the code between the construction of the class and the calling of its methods, so that control_object cannot always fulfill my goal of replacing its methods with "sympathetic" methods, and the core edit is, after all, still necessary.

I did check the PM handler object, I think it is fair to add some hooks, Most likely directly in the data handler files, around:
https://github.com/mybb/mybb/blob/8b22ad...m.php#L470
https://github.com/mybb/mybb/blob/8b22ad...m.php#L582
https://github.com/mybb/mybb/blob/8b22ad...#L175-L176
https://github.com/mybb/mybb/blob/8b22ad...#L130-L131

Maybe none of exactly these but rather others, should probably be discussed separately.

A hook around the following line could alone probably allow you to control the object for your plugin (idea, so you could reduce to only 1 core edit):
https://github.com/mybb/mybb/blob/8b22ad...er.php#L71

(2021-02-25, 10:34 AM)Laird Wrote: [ -> ]I'm definitely gonna have to investigate this xThreads business! Where would you suggest I start?

This plugin works mostly because of this function without core edits (I should probably suggest some hooks on my own). Some of Shade's recently released plugins also work with it.

(2021-02-25, 10:34 AM)Laird Wrote: [ -> ]I'm definitely gonna have to investigate this xThreads business! Where would you suggest I start?

https://ougc.network/entry?how-to-hide-x...s-a-thread

Quote:I'm digging into the code to see if I can see a reason for this, but just thought I'd raise the question here and now in case anybody has an immediate answer.

Interesting find, but I won't be sure for the reason, but if you can replicate maybe you could open an issue thread to track it down.
Regarding your original replies @Laird, I think that instant replying isn't always necessary nor the best. Sometimes time is required to avoid living by reaction and give people the opportunity to think about what they did or said, specially if confusion is a possibility.

That is what it seems @Sharee did so we are free to move on Wink
(2021-02-25, 11:28 PM)Omar G. Wrote: [ -> ]Regarding your original replies @Laird, I think that instant replying isn't always necessary nor the best. Sometimes time is required to avoid living by reaction and give people the opportunity to think about what they did or said, specially if confusion is a possibility.

That is what it seems @Sharee did so we are free to move on Wink

Yes it seems to have fixed the issue. The following ALTER query was the solution. Thanks to all of you.



ALTER TABLE `mybb_threads` ADD INDEX `fid3` (`fid`, `sticky`, `lastpost`);
(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]I did check the PM handler object, I think it is fair to add some hooks, Most likely directly in the data handler files, around:
https://github.com/mybb/mybb/blob/8b22ad...m.php#L470
https://github.com/mybb/mybb/blob/8b22ad...m.php#L582
https://github.com/mybb/mybb/blob/8b22ad...#L175-L176
https://github.com/mybb/mybb/blob/8b22ad...#L130-L131

Those seem like useful hooks, yes. Generally, I think the more hooks the better. Extensibility and options for extension are a very good thing.

(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]Maybe none of exactly these but rather others, should probably be discussed separately.

Yes, for sure.

There are a few other hooks that would be helpful for me for MyConversations in particular, and maybe helpful for other MyBB plugin developers too - I just haven't gotten around to collating them and advocating for their addition.

In particular, I was forced to resort to an unreliable and ugly hack to implement plain-text parser output support for quote tags using an mid attribute (conversation message ID) as opposed to core's pid quote tag attribute. HTML parser output support for this attribute didn't require a hack though.

(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]A hook around the following line could alone probably allow you to control the object for your plugin (idea, so you could reduce to only 1 core edit):
https://github.com/mybb/mybb/blob/8b22ad...er.php#L71

Mmm, I'm not quite sure what you're suggesting here. Can you elaborate a little?

(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]This plugin works mostly because of this function without core edits (I should probably suggest some hooks on my own).

Huh. Very interesting. This plugin of yours looks like an alternative version of MyConversations, where private threads are used in place of private "conversations", leveraging, no doubt, all of the existing functionality of showthread.php rather than, as MyConversations does, pretty much duplicating it.

(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]Some of Shade's recently released plugins also work with it.

Neat. I haven't looked too closely at those plugins yet, although I have downloaded and taken a very brief skim through Symposium.

(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]https://ougc.network/entry?how-to-hide-x...s-a-thread

Thank you. I think I'm now starting to get an idea of the basics of XThreads: it makes it possible to add custom fields to core threads, and to display those fields in various ways. Does that sound like a reasonable (but more importantly, sufficiently comprehensive) description?

(2021-02-25, 11:22 PM)Omar G. Wrote: [ -> ]Interesting find, but I won't be sure for the reason, but if you can replicate maybe you could open an issue thread to track it down.

I have come to the conclusion that the explanation does not lie with MyBB but with some quirk of the mysql commandline client. I have reached this conclusion because even when I disable query caching altogether via SET GLOBAL query_cache_type = OFF;, the time for the query in question (via the mysql commandline client) remains at its low mark of around or under a millisecond, and doesn't revert to the initial value I saw of around 150ms. Also: as well as being unable to produce this longer execution time via MyBB's debug page, I cannot reproduce it via phpMyAdmin either. It seems to me, then, that this lengthier execution has nothing to do with the query not being cached and everything to do with the way that the mysql client interacts with my MariaDB server for a first query of this type. As for what that issue is, I don't care to investigate further! I just know now that the first execution time provided to me by the mysql commandline client for a query cannot be trusted. The query needs to be run a second time to get the correct value.

(2021-02-25, 11:28 PM)Omar G. Wrote: [ -> ]we are free to move on Wink

OK. I sure hope so.
Quote:Mmm, I'm not quite sure what you're suggesting here. Can you elaborate a little?

Never mind, I can seem hooks being useful in the following places:
https://github.com/mybb/mybb/blob/8b22ad....php#L8798

And then use this function in all places that send PM (enhancement might be necessary). I think this function needs a hook, even if the data handler get some too.
Pages: 1 2 3