Looks like my re-do of the site software and database was only marginally successful: Caching seems to work, so people who aren't logged in seem to get pages served up pretty quickly, but the server is still wheezing and people with accounts are having major page-loading issues - I've seen server loads as high as 21.
So: I'd love to hear proposals from folks who know MySQL and Drupal 7 (the site is actually running on Backdrop, which is a Drupal 7 fork, so the basics will be similar, but, hey, if you've worked with Backdrop, all the better ...) on how you'd diagnose what's going on and suggest fixes - and, of course, how much you'd charge.
Basic site info: It's hosted on a dedicated server (at Pair.com), running Ubuntu, MySQL 5.7 and PHP 7.4.33 with, I think, 16G of RAM.
You can reach me at [email protected]
Thanks!
Like the job UHub is doing? Consider a contribution. Thanks!
Ad:
Comments
We're Patient
By Nikkinunu1977
Fri, 03/07/2025 - 6:00am
I just wanted to drop a few lines to say that I think you're doing an amazing job we appreciate all your work here on you hub I come here first thing every morning in all throughout the day to check on the news so I appreciate you and we will definitely be very patient and appreciate all your hard work Adam much love!
it seems like a basic lamp configuration:
By schneidz
Fri, 03/07/2025 - 6:54am
i've administered a bugzilla installation for a doble corporation in watertown while in college.
i dont have much experience with performance analyzers but without examining code, my gut hunch is the server logic is unnecessarily trying to search for all the users posting/voting history for every page they navigate to ?
another hunch
By schneidz
Sun, 03/09/2025 - 9:22am
memory leaks.
duzz php have a free() function;
?
iz phpmyadmin still ħə goto web admin panel ?
Doesn't need one
By Tim Mc.
Fri, 03/07/2025 - 7:14pm
PHP is shared-nothing -- all of the resources allocated during a request-response cycle are collected at the end.
A memory leak would be an easy thing
By robo
Sat, 03/08/2025 - 7:33am
To diagnose. A bitch to fix though.
Could be as simple as adding
By Anonymous
Fri, 03/07/2025 - 7:46am
Could be as simple as adding an index to a field that needs it. MySQL queries are sooooo much faster when properly indexed. (Also, MySQL 5.7 is long-since deprecated.)
Additional problem could be...
By Kaz
Sat, 03/08/2025 - 3:09pm
MySQL is really good at suddenly deciding that your query can't filter first down to ten rows from one table, then merge with nine other tables to return 10 rows of data, it has to merge your 10 biggest tables into one ginormous table of billions of rows...THEN filter down to the 10 rows you wanted back.
That all gets written to disk temporarily and that means everything else waits until it's done and now everything slows down and backlog and load goes up. Then it throws the merged table away and the next request asks it to merge the same tables again, yay!
Often you have to change the query or add a more complex index to convince the interpreter to filter first, then merge the rest in.
The old, no longer supported
By Frelmont
Fri, 03/07/2025 - 7:48am
The old, no longer supported software, and old software in general must have been the efficient product of human genius, ingenuity and artfulness to perform in a “low” processing environment. With faster processors computers are just as slow owing to information greed and greater, constant unnecessary demands.
uh
By berkleealum
Fri, 03/07/2025 - 12:31pm
this comment removes all doubt, right? it's an AI
but, the CAPTCHA though…
By Frelmont
Fri, 03/07/2025 - 7:45pm
but, the CAPTCHA though…
Now this removes all doubt that you are insulting me and aren’t questioning [the fact of] my humanity (well, maybe my sense of humanity.)
““Now, the accusations have become more like an insult, dehumanising people, insulting them, and using this as a technique to deny their intelligence and deny their right to participate in a conversation,” says Assenmacher.” -*
*https://
www.newscientist.com/article/2434742-the-word-bot-...
Darmok and Jalad
By Sator
Fri, 03/07/2025 - 8:57pm
At Tanagra
Jeff
By Jeff J
Fri, 03/07/2025 - 9:09am
Seen something similar where the old user sessions were not closing. We added something to log users out with a warning message first.
As an experiment try disabling the ads
By FakeBostonCharlie
Fri, 03/07/2025 - 9:46am
Some ad servers are very greedy of resources, and have even been known to do evil things like crypto mining.
Indexes?
By Doug L
Fri, 03/07/2025 - 10:19am
This may be too basic to point out, but when you migrated your database tables did you also migrate the relevant indexes? Otherwise the db has to read the entire contents of the table to do a query.
One particularly lazy and
By Bob Leponge
Fri, 03/07/2025 - 3:48pm
One particularly lazy and ignorant-of-the-tools but sometimes informative approach I have taken while swinging wildly in the dark at performance analysis, is to temporarily host the web tier and the database tier on two different physical hosts....
Definitely a useful
By MattyC
Fri, 03/07/2025 - 4:50pm
Definitely a useful experiment to see where the failure load is being seen
That's my day job
By Kaz
Sat, 03/08/2025 - 3:12pm
I don't do Drupal but I do WordPress and MySQL (you really should update to 8.X. It's not necessarily a performance boost or anything, but we also had basically zero issues with our own migrations from 5.X to 8.X so you might as well bite that bullet).
Are you running your own MySQL database on the server or is it something pair.com administers/provides as a service? Are you able to generate a slow query log ( https://dev.mysql.com/doc/refman/5.7/en/slow-query... ) anywhere that you can retrieve it and examine it? It will help you figure out just what is slow on the DB. I'd say anything taking more than like 2-5s is probably a slow query for starters...if that generates too much noise, up it to 10s. Start working on the worst queries and drill down (or the ones that run the most often even if they're faster but should be fractions of a second). If you have anything like the equivalent of AWS RDS Performance Insights, it's a godsend.
Other than that, do you even know which part of the front-end is slow? I know that posting comments is pretty slow on saving and returning to the article. I don't know if it's the write to the DB or the recall of what the page state should be that is the slow part, haven't tried diagnosing it from my browser yet. But that could also imply what part of the drupal/frontend code is creating the query that's slow. If the DB has nothing going slowly, then it may be that the webserver software (nginx or httpd?) is having memory issues compiling everything it gets back from the DB before serving it to the client, but that's less likely in this day and age I would think.
Just some initial thoughts. I can reach out to you by email and see if you want any real-time help on a call or something.
EDIT: I watched in the browser as I posted a reply up above. The POST took ~10s and the GET rebuild of the article page took another 10s before it all finished up. So, both actions were taking time and not particularly the save or the page refresh is the problem in case that helps. Let me see if this comment edit has the same issue.
EDIT2 - Very interesting the edit and the page rebuild afterwards only took 2s each...hmm.
hackathon ?
By schneidz
Sun, 03/09/2025 - 9:33am
maybee host u hackathon wun weekend aftərnoon sō us weardōz ken brake-owt toogeħər and mash-up ħə website eeven mor ?
Add comment