Problem with posting, need static site

[xeneum]

I'm setting up my site and I have everything working that I want, but whenever you make a post it rearranges the threads and categories and the sub threads on them.

My test site.

66.150.121.115/index.php?action=forum

Any easy way to fix this?

It's suppose to be in this order, but it changes it by itself and completely ignores the admin order. I also am running mysql if that helps at all.

community
xeneum servers
help and support
bans and appeals
media gallery

[Kindred]

Welcome to SMF.

I am not certain what you mean...

Threads in the message list get sorted by the most recent response.

Unless you have installed mods, the boards get sorted by the admin order and don't change... Of they are changing order, then you must have installed some sort of mods to change the base behavior...

What mods do ou have installed?

[Illori]

sounds like mysql 5.6 issues where the board order is not correct. there is no fix for 2.0 for this. it requires a total rewrite of the board index code.

[JBlaze]

sounds like mysql 5.6 issues where the board order is not correct. there is no fix for 2.0 for this. it requires a total rewrite of the board index code.

Haven't heard of this. What's the issue, exactly?

[Arantor]

SMF relies explicitly on the boards table being in the right order, so that it can do a simple table scan rather than a table scan + filesort because we have fulltext columns.

Now, InnoDB has always been bugged in this department because InnoDB always orders by primary key - not the board order. The solution for this is to force the board_order to be the primary key for InnoDB and then make id_board a UNIQUE. But since we default to MyISAM this wasn't a problem.

But in 5.6+, it seems that MySQL no longer behaves the way we've always expected.

Now we could just fix it with a simple ORDER BY in all the places it matters, but that will have a serious performance overhead compared to what we have right now.

[JBlaze]

Ah, I see. I haven't been following MySQL development for a while. Interesting, though.

Is this something that can be easily patched, or best left alone for now?

[Arantor]

We can do a crude patch for 2.0, but 2.1 requires more finesse.

[xeneum]

 If it is a mysql problem is their anyway to go about fixing it? If there is going to be a crude patch how long will something like this take; so I know how long I have to wait.

[Arantor]

That depends on your server configuration and how much performance you're willing to lose.

Or that you wait for us to finish rewriting one of the oldest and ugliest parts of SMF.

[xeneum]

How long will the rewrite take? I might be willing to lose the performance if the update is soon, and if we are talking about reads/writes with mysql; my mysql is install on 5gb ssd partition so i wouldn't think it would be a problem on my dedi.

[Kindred]

2.1 will be done when it is done...

And the disk space is not the issue with the performance...   

Also, we have not confirmed that your reported issue is actually related to the MySQL issue that they are discussing.
It depends on you actually clarifying what you actually mean by "it changes by itself"

Do you mean that it uses a different order than you have defined or that it actually changes from view to view?

[Arantor]

The rewrite will come with SMF 2.1 which will probably be some months before a stable release (it's all on Github)

The problem in question is the board list query is applied in a lot of places. The board index, every board's listing of topics, the jumpto and a bunch of other places are all affected and all slowed down.

Where possible, queries should be organised in memory - except the query in question if reorganised will require writing to disk in a temporary file. Which means they ALL get slower. While an SSD is fast, it's still an order of magnitude slower than doing it in memory.

There is a reason this code basically hasn't changed in ten years.

[xeneum]

I meant with the disk space, that my mysql is on a ssd rather then a hard drive so im wondering if the reads/writes will increase with the fix?

[Arantor]

Yes, every single related query will make MANY MORE WRITES even when it's a read only query.

[xeneum]

Would going back to an older version of mysql fix this? Just out of curiosity.

[Arantor]

That depends, like I said up front, on your configuration.

[xeneum]

I'm kinda dumbfounded but what do you mean by configuration the way we installed mysql or the way we installed smf?

We just used a basic install with this package x64, everything stock just different username + password

hxxp:dev.mysql.com/downloads/mysql/ [nonactive]

I also install phpmyadmin b/c I like using that rather then having to startup the workbench.

[Arantor]

You haven't even told me what version of MySQL you're using. There are multiple different versions which can exhibit the same problems.

Secondly, it depends on what type of tables you're using. Whether you're using MyISAM or InnoDB tables, which is usually a configurational thing at MySQL's level.

[xeneum]

Sorry, I'm using Mysql Version 5.6.14 as for the tables; phpmyadmin shows them as MyISAM according to ~ SHOW TABLE STATUS FROM

[Arantor]

In which case, MySQL 5.5 with MyISAM should work for you.

[xeneum]

Alright, Thank-you. In doing this I am able to export the old database and use it with mysql 5.5 or would i need to do a fresh install + new database? I just wanna be sure that way I don't run into any problems down along the line.

[Arantor]

You should be able to do an import without any problems. But a fresh install wouldn't hurt either if that's not a huge problem.

[xeneum]

Thanks. I'm doing a fresh install right now to test it. I'll get back to you in a few.