Something big is coming....

[DisAlex]

Two issues - the migration is done and dusted, no point going over that. Second issue is that increasing the current RAM will make zero difference, increase it if you want, but you may as well change the color of the server case while you are at it. Trust me, you've already got oodles of RAM, much more than busier systems than yours. You've got to look at things like query cache size, too small and your db will be going needlessly back to disk and having to recalculate everything which has a hit on CPU and will make your site slower.

I agree with you 100% and have been tuning all of the parameters since we started! I never said I didn't or wouldn't etc. Tuning is more important than just throwing gobs of RAM at a problem BUT tuning with gobs of RAM is even better
The current servers are Dell and only come in Dell Grey but the new ones are HP and I personally find their aesthetics preferable, I'm sure they will run faster since they look better!

 

[Jim Boy]

I can't emphasise enough the importance of 'go-faster stripes'

 

[thedude]

You cant just put in a MySQL/MariaDB server with a heap of RAM and expect it to do the job. You really need to tune it. Our db server only has 15GB of RAM, yet we have had 8000 concurrent users - the database cruised through that, instead core failings in the XF code start to come into play at those magnitudes. Throwing more RAM in is a complete waste of money.

Were these issues addressed, or did you work around them?

I can't emphasise enough the importance of 'go-faster stripes'

 

[Jim Boy]

Were these issues addressed, or did you work around them?

Worked around them - I have an open bug report that should get addressed in XF2. Reality is that while XF is designed to handle reasonably large cases, it is not designed to scale.

 

[digitalpoint]

Worked around them - I have an open bug report that should get addressed in XF2. Reality is that while XF is designed to handle reasonably large cases, it is not designed to scale.

I'm curious what the issue is exactly? Awhile back I did a load test on my XF setup and it was able to handle 100,000 concurrent users, each requesting a random thread to view every 3-5 seconds without any issues or slowness.

 

[Jim Boy]

I'm curious what the issue is exactly? Awhile back I did a load test on my XF setup and it was able to handle 100,000 concurrent users, each requesting a random thread to view every 3-5 seconds without any issues or slowness.

I assume you were using guest or a single user. The information about users online collects lots of info about all the users online as defined in XF at a given time, they have to be unique users, not the same user (including guest) logged in simultaneously. It then delivers all that info to the phpscript. 6000 users roughly equates to 128MB of php script. If you have 128MB as maximum memory for a script, which should be more than enough for XF, which normally only requires about 12MB, then the script will crash. Of course you can allocate more memory per script, but if you were doing 100,000 concurrent users, you would need to allow 2GB per PHP script, which would mean you would need about 6TB of RAM in your web server.

 

[digitalpoint]

Oh are you talking about the users online block? Yeah... I replaced that with my own more efficient function a long time ago. Thought it was crazy that it spun through every online user just to show the 50 most recent or whatever.

For my test it was unique registered users.

 

[RobinHood]

Something big is coming....

(51,447,222 records in 5,073.71s)...

Literotica?

We just went public on our boards

http://www.disboards.com

Close enough!

Congrats on the move, looks good

 

[DisAlex]

Close enough!

Congrats on the move, looks good

Ok that made me laugh Literotica we are not!

 

[rafass]

awesome numbers. welcome!