News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Overloading of some sort

Started by tjbalon, June 26, 2016, 09:05:25 PM

Previous topic - Next topic

tjbalon

Hello All,

So I plan on moving my website to nginx, php-fpm, & mysql. After beta testing it for a few days, I had about 30 people try to load the website all at once, and it crawls. Down to about a 10-20 second load time. On our current website, (php5, apache2, mysql) + much weaker hardware, there seems to be no issue at all.

My assumption is I have something wrong in a config which is causing this, but not too sure what it could be.

Any advice would be great, I can post configs, etc if necessary.

LiroyvH

Yeah we're gonna need more background information. Old specs, current specs would be nice for starters. (Including software + versions. Also; VPS or Dedicated?)
Also, have you checked what's causing the crumble? CPU? Memory? I/O? (Note: high i/o wait can cause the CPU *load* to look very very high on a linux server, whilst it might not be the CPU that's truly being stressed. So check for iowait values as well)

Have you checked which queries are taking long? (Eg: check the mySQL processlist or enable debug?)
((U + C + I)x(10 − S)) / 20xAx1 / (1 − sin(F / 10))
President/CEO of Simple Machines - Server Manager
Please do not PM for support - anything else is usually OK.

tjbalon

Shared, previously (specs not exactly known) to a VM on a dedicated machine.

Machine has:
Web:
4 x 1630v3 Cores
8GB Ram
256GB SSD

SQL:
2 x 1630v3 Cores
8GB Ram
256GB SSD

CPU seems to be doing perfectly fine. No higher than 9% on 1 core according to htop on the SQL server. 15% on the web-server.

I can try to enable debug and see if that points towards anything.

tjbalon

For any of you who switch to nginx but have problems with high traffic == slow loadtimes, read here:

https://www.nginx.com/blog/thread-pools-boost-performance-9x/

Nginx 'saves time' by not context-switching the CPU from request to request, meaning that if one has a large delay, all that follow go shorter. Shutting the mutex locks will allow proper context switching, I believe moved onto shortest job first ( https://en.wikipedia.org/wiki/Shortest_job_next ) to complete it's tasks, or something similar from days of testing.

The biggest enemy here is the blocking operation. As of my post, problems have cleaned up. I 'should' have stuck with apache for something as of this, maybe it's the size of my forum that did not help, but with this change load times are under 0.6s, which are impressive from our old average of 2.98 -> 4.19.

Hope this helps someone some day.

Advertisement: