Calguns Really Back?

[SactoDoug]

Is this real? Is Calguns finally back?

[Term]

No it's just a dream , go back to sleep.

[saudadeii]

Was running pretty well early this am. Now that the word has spread, folks are jumping back in and it's slowing down. (again!)

[TrappedinCalifornia]

As Kestryll said, it's open, but with a 'few issues.'

He knows it's slower than a Joe Biden reply at times. I assume he knows about some of the other issues; e.g., tried posting images and all I get are "no directory exists for attachments."

But, given the rush from .org back to here, I'd say people are happy it's back up and running.

Fixes for the issues and the timing thereof, including the speed of use and the times when things slow? Who knows? Even Kestryll acknowledges he doesn't yet.

However, as they say...

Okay. We need our own theme song.

[Garbcollector]

Probably it will take another 6 months to a year to get it working correctly I'm guessing

[BucDan]

Website is slow again every now and then like before the cloud migration.

[prob]

Dial up slow. Again.

[SactoDoug]

I think the site needs two strong servers or three regular servers load balanced. A single server just can't keep up.

[saudadeii]

Well, there are over 3000 “guests” logged in right now. Perhaps the site should be restricted to logged in “members”

[Librarian]

I think the site needs two strong servers or three regular servers load balanced. A single server just can't keep up.

I suspect, with my very limited understanding of forum software and hardware, this may prove true.

I just got a gateway timeout trying to use the 'Quote' function to reply Failed on retrieving quotes.

And after posting, it took about 50 seconds from hitting the browser back button to getting the list of topics page. That's Not Good.

[5.56Geo]

Wonderful!

[one*eyed*jack]

So far so good. Glad to see it's back! Congrats.

[Kyle1886]

It has been hit and miss for me since about 0300 this AM. The last 10 minutes or so have been fine. But I do find it hard to believe there are 3260 guests and 24 members on site at the moment.

Respectfully
Kyle

[Kyle1886]

It seems 0300 hrs or about is the magic number for CG to have its little fits. The usual gateway and a couple of errors I have not seen before, one being a 502, I got on about 0230 hrs and the site ran great about a half hour. Multiple tries to get back on were unsuccessful until a bit after 0400 hrs. Very similar as yesterday.

So is something set to backup/run around 0300 hrs?

Just thinking out loud...

Kyle

[command_liner]

It is good to see the forum up and running again.

I used to get paid to assist is performance tuning on RHEL systems that ran 5000 real-time threads to make 2 billion binding decisions
per second -- for hours at a time. Much bigger problem than running a forum on a CentOS box, but the lessons are quite similar. When
I mentioned a mid-range system (like the HP Gen9 ML 350) with the Intel fabric-switching Xeons, it was for a reason. Also the idea of
multiple fully-populated DDR4 channels is important. TCP tuning is important, use of NVME is important, turning off swap is important, and
turning off overcommit is important. Probably important here is NUMA steering: the threads should not be wandering across the NUMA
bus -- the databases should stay on one physical CPU and the database on another.

A mid-range server will start with 4 10G ethernets for communication. One can add more if needed... put the cards on the same PCIe
bus that is attached to the CPU group that is writing HTML to the cloud.

Contexts switches are important, and with 5000 users, there will be lots of context switches. Very often nobody tunes the TCP buffering,
which means the stock 4K buffer is used. OK, but that means there are something like 10,000 context switches per page refresh (as
viewed from the browser). What is the specific page fault rate at 100 users, 1000 users, 5000 users?

The 504 and 503 HTTP errors are probably pointing out insufficient TCP connectivity inside the HTTP time window. When the TCP
stack is full, the kernel just dumps requests, which breaks the overlaid HTTP transactions we all like.

The database.... is setup how? Queued transactions? Are all activities at the same priority?

I see there are still millions of improperly configured data objects being sent from the pages. Turn off JPEG, ZLIB, and everything else that
is not zstd with max compression. This will cut the data volume (I am guessing) 2:1 almost immediately. Which will cut the TCP-caused
context switches and page faults in half.

Third party references (EG XLturners468x60.gif, and the like) are still slow. But internal data fetch is very very slow. It should not take
even a millionth of 179 seconds to server up the HTML page object for "announcements-and-suggestions". So there is a speed up
factor of a million available somewhere in the configuration. Please find it and apply it.

Just dumping vBulletin on a consumer grade PC and hoping it will work OK is not a workable plan. Adding more un-configured boxes
to the execution pool may be a viable (and cheap) approach. Fully tuning a box is hard but valuable.