XF 2.1 Slow installation

Gilly

Member
I have a friend that gave me permission to access this area. Is there a reason why the installation is very slow?

We have three test benches-- here are the specs for each:

Linux Testbench:

OS Tried: Ubuntu 18.04, 16.04. Debian 7, 8, 9
CPU: Intel Xeon E5-1630v3
RAM: 64GB DDR4 ECC 2133 MHz
HDD: 2TB 7200 RPM


Windows Testbench 1:

OS Tried: Windows Server 2008R2, 2012R2, 2016, 2019
CPU: 2x Intel Xeon X5690
RAM: 128GB DDR3 RAM 1600 MHz
SSD: 2x Seagate SSDs
HDD: 4x Western Digital SAS 10K RPM


Windows Testbench 2:

OS Tried: Windows Server 2008R2, 2012R2, 2016, 2019
CPU: 2x Intel Xeon Gold 6244
RAM: 192GB DDR4 2666 MHz
SSD: 6x Samsung Pro

On all of our installation tests, we have seen that it ranges from 1 hour and 45 min to nearly 5 hours. We did find some posts on here Xenforo.com that said "it should only take a couple of minutes" from one of the moderators. We have tried it on an SSD as well as on an HDD. I have tried it on my local computer I will list the specs below, which is the only time it took less than 5 minutes:

CPU: Intel i9 9900K
CPU Cooler: Corsair H115i RGB Platinum
SSD: Samsung SSD 970 EVO Plus
RAM: 32 GB DDR4 3000 MHz Tridentz RGB
 
Even slow consumer-level hard drives have more than adequate transfer rates for the amount of data being transferred during installs. SSD or HDD, it's not going to make a difference with a rebuild if mysql is optimal, and the example hardware you gave has more than adequate RAM to do so.

Some notable issues:

innodb_flush_log_at_trx_commit=1 - change this to 2. While 1 is a great setting for missing critical applications where every write can't be lost, it slows write performance. With a setting of 2, it's much faster, and at most you could lose 1 second of data if power is lost.

innodb_buffer_pool_size=8M - far too small. This setting is one of the single most important settings for Innodb performance. It needs to be at least as large as the total largest anticipated size of all Innodb tables, plus about 15%.

innodb_buffer_pool_instances = 8 - this is completely useless except for when the above innodb_buffer_pool_size size is multi-gigabytes. General rule of thumb is 1 buffer pool instance per gigabyte of buffer pool size, up to about 32 instances (at that point go ahead and have each buffer pool larger than 1 GB). On high concurrency systems with plenty of CPU cores, it may be of benefit to use more instances than 32, but forums generally don't fit in this category except for very busy boards.

There are other issues in it as well, but I have a scheduled client task to get to, and those first two recommendations will go a long way towards speeding things up.

Well... I must say, I can't complete I overlooked the innodb_buffer_pool_size setting when I optimized that database server long ago! :o

I made a test VM running on our dual-socket Xeon Gold 6244 workstation with a type 2 hypervisor, and oh-boy did your suggestions make a huge difference.

VirtualBox VM specs (to be as close to our production server as possible):
  • Windows Server 2012 R2 Datacenter OS
  • IIS 8.0 webserver
  • MySQL Server 8.0.11
  • 1 vCPU (Xeon Gold 6244)
  • 8GB DDR4 RAM
  • 60GB HDD on a physical 7200rpm HDD

I first ran the installation with all default server settings, installation time was 18min:11s.
After your suggested optimizations, I ran the installation again, this time installation was 1m:36s.

That is definitely a huge improvement, and certainly a speed I'm satisfied with as that is on-par with all the other software I've installed in the past. Very many thanks to you (and others as well) for taking the time to provide some constructive advice given our little personal conundrum lol :)

Cheers once again! (y)
 
Waiting for a answer it`s a virtue... rushing and blaming xF for slow installation it wasn't nice. Glad you got your optimization guys. Cheers.

I am absolutely glad that we figured out a solution for this, for sure. Please note that, I/we was/were not trying to blame XF for the slow installation, but rather wondering if anyone else had the issue since this seemed to be the only software that we had such an experience with. In truth, so far I/we am/are happy with XF, even though I have personally noticed that the way it works sometimes is just a tad different here and there compared to other forum solutions. But alas, we are glad these optimizations were able to greatly help us with our issue!

Cheers!
 
Most of us din`t had that issues with the install... when other try to point you guys for an optimization setting, you guys just blow up, demanding you already did it... obviously not. Anyway... glad you sort it out. Good job @MySiteGuy . Cheers pal.
 
Most of us din`t had that issues with the install... when other try to point you guys for an optimization setting, you guys just blow up, demanding you already did it... obviously not.

I did not blow up toward people who gave constructive advice. I blew up toward people who appeared to be giving sarcastic remarks, which seemed to suggest that we're idiots who don't know how to setup a simple server. I responded as I saw fit to others responses. I do not appreciate when people jump to the gun and think they know everything simply because they don't have the issue.

Sort of like your post, suggesting that it again was all our fault, assuming we did no optimizations whatsoever. I did do optimizations elsewhere, and like I mentioned numerous times, other software worked just fine, mind you, even without such optimizations. Just because I didn't optimize those two settings hardly means I didn't do any optimizations.

Also, common sense suggests there is something to be said about things that require such specific optimizations. If other software of the same caliper run just fine without such optimizations, why is that? There must be something particular going on to cause it, so the software is partially to blame— otherwise other software wouldn't work without such optimizations.

It is very convenient that everyone wants to hop on the train to defend XenForo and kiss its ass (for lack of a better term, please pardon my language), but again, we too enjoy the software and aren't looking to bash it. No one so far seems to even acknowledge the fact that all the other forum software installed quickly without a hitch unlike XF, either with or without such optimizations.
 
Last edited:
Well... I must say, I can't complete I overlooked the innodb_buffer_pool_size setting when I optimized that database server long ago! :eek:

I made a test VM running on our dual-socket Xeon Gold 6244 workstation with a type 2 hypervisor, and oh-boy did your suggestions make a huge difference.

VirtualBox VM specs (to be as close to our production server as possible):
  • Windows Server 2012 R2 Datacenter OS
  • IIS 8.0 webserver
  • MySQL Server 8.0.11
  • 1 vCPU (Xeon Gold 6244)
  • 8GB DDR4 RAM
  • 60GB HDD on a physical 7200rpm HDD

I first ran the installation with all default server settings, installation time was 18min:11s.
After your suggested optimizations, I ran the installation again, this time installation was 1m:36s.

That is definitely a huge improvement, and certainly a speed I'm satisfied with as that is on-par with all the other software I've installed in the past. Very many thanks to you (and others as well) for taking the time to provide some constructive advice given our little personal conundrum lol :)

Cheers once again! (y)

I'm very happy to hear this!
 
We run a t3.medium instance in AWS along with Centminmod. Without any configuration changes our clean installs and subsequent updates generally take a minute or two. In certain instances after reading your server specs throughout the thread it sounds like you’re trying to run XF on a gaming rig (NVMe SSDs, i9 9900K CPUs, etc,). I hope you found your answers as I don’t think it’s very wise or polite to take Brogan or any other XF staff member here to task and beat a dead horse over four pages.
 
  • Like
Reactions: eL_
In certain instances after reading your server specs throughout the thread it sounds like you’re trying to run XF on a gaming rig (NVMe SSDs, i9 9900K CPUs, etc,).

One of the gaming rigs was a test-bench to show that we only got acceptable installation times on a high-end system. The rest were either workstations or servers, but indeed were all used for test-benching.

I hope you found your answers...

We did.

...as I don’t think it’s very wise or polite to take Brogan or any other XF staff member here to task and beat a dead horse over four pages.

Don't know what you're on about... no one asked Brogan or any other XF staff member to beat a dead horse.
 
Right no one ask that... you guys just explode when @Brogan try to give you an simply answer, like it was his fault or xF staff, for your misunderstand of the setup. Anyway... let`s stop it here. Welcome, hope all goes well with you guys.
 
What I found interesting was, the very thing @MySiteGuy suggested that worked, was suggested much earlier in the thread. But somehow missed. Or not tried. Either way, good to see the issue is sorted.
To be fair, Brogan gave as much information as possible when he mentioned MySql configuration and gave links in the 4th reply in this thread, here. The very first link gave recommendations on innodb_buffer_pool_size in the first MySql settings.

Seems that helpful bit was overlooked from the start. Someone was looking for a definitive pinpoint answer which isn’t really possible when so many variables are at play.
 
Right no one ask that... you guys just explode when @Brogan try to give you an simply answer, like it was his fault or xF staff, for your misunderstand of the setup. Anyway... let`s stop it here. Welcome, hope all goes well with you guys.

I wasn't initially attempting to blame XF, only point out that XF was the only software that saw this issue for us, while others didn't. So it was a fair assumption that XF was doing something different-- though not necessarily wrong. I exploded later yes, which appeared to be out of a misunderstanding.

Seems that helpful bit was overlooked from the start. Someone was looking for a definitive pinpoint answer which isn’t really possible when so many variables are at play.

This. That part was overlooked, but in addition, was not the only setting that adjusting seemed to help.

What I found interesting was, the very thing @MySiteGuy suggested that worked, was suggested much earlier in the thread. But somehow missed. Or not tried. Either way, good to see the issue is sorted.

It was suggested, but that was not the setting that seemed to make the most difference. That did seem to save about 3 minutes of installation time, but of course in the end it still took 15 minutes which was still far from what others were reporting. Indeed MySiteGuy nailed it when he mentioned the other setting. :)

Someone was looking for a definitive pinpoint answer which isn’t really possible when so many variables are at play.

Very true.

And we're definitely glad that we seem to have got this sorted, so cheers to all that helped, including @TickTackk, @MySiteGuy, @Xon, and @Brogan. And apologies to all those who I detonated on. :D
 
Last edited:
But... It's all the same setting.

What are you talking about?

The setting originally suggested was:

Code:
innodb_flush_log_at_trx_commit

and

Code:
innodb_flush_neighbors=0
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_io_capacity=3000

But the most significant difference was after altering this setting:

Code:
innodb_buffer_pool_size

So, either the last suggestion made the biggest difference or (most likely) the accumulation of all the suggestions ended up making the most significant difference. They are all indeed related but are not the same settings.
 
the accumulation of all the suggestions
Were ignored for quite some time. Either way, finally you took a real look and solved the issue, which was not xenforo itself as it turned out.

It seemed you were more interested in typing highly verbose circumlocutory pleonastic grandiloquent replies and arguing, than you were with solving the problem. Finally you came around.
 
  • Haha
Reactions: eL_
Were ignored for quite some time.

They weren't ignored, so quit wasting everyone's time with such useless replies.

Either you didn't read anything I said in the above posts, or you're not competent enough to comprehend anything, so I will leave it at that. Frankly, I'm tired of repeating myself. Your previous post made no sense and yet you continue to babble on nonsense...

...which was not xenforo itself as it turned out.

XF is still partially to blame, as it does things in a not-so-efficient way as someone generously pointed out many posts ago. But indeed, some further optimization of the database server helped.

It seemed you were more interested in typing highly verbose circumlocutory pleonastic grandiloquent replies and arguing, than you were with solving the problem. Finally you came around.

Right, I just wanted to waste my precious time, as well as the time of others ( ͡° ͜ʖ ͡°)...... :rolleyes:

Anyways, quit crying about it and get over it. Let this thread die— the problem was solved, case closed. Special thanks to all those who provided constructive advice and links, and thanks but no thanks to those who babbled and wish to continue their endeavours.

Anyone else wants to waste time beating this dead horse of a thread, knock yourself out. I'm out.
 
Last edited:
XF is still partially to blame, as it does things in a not-so-efficient way as someone generously pointed out many posts ago. But indeed, some further

Early on you said you didn`t blame xF... Geeez... you`re so funny... Look like you have that type of personalities to blame others when you are frustrated.
:D:D
 
Top Bottom