This is my website, although I doubt that the issue is there (subject to correction). It’s not a social media website; just a small fanbase.
Situation
Overtime I’ve realized that every process is becoming slower, especially when processing information in the MySQL database on InfinityFree. My website is taking longer to create approvals (some people call it “liking a post”), uploading images is fine but to do simple stuff like “disproving” a post (marking it so that the bot can log a report), other features like returning (a.k.a logging in), creating a post and other things are incredibly slow.
TLDR
Is it just a non-premium thing that is being adjusted, is my server hanging, or am I doing something wrong?
Well besides the fact that it took 42 seconds to lead your website, three resources were not found (404), and one of the files has an error on line 45095, all looks good.
Oh, and that blue background is hard on the eyes.
Most likely, the actual database changes are going at normal speed (A tiny fraction of a second), it is taking your page forever to load because you are requiring tons of scripts (97), and the browser has to process each and every one.
So I would say that the issue is is how you built your website, and the insane number of resources you are requiring the browser to parse.
EDIT:
You know the issue is with your site because Google Lighthouse even throws a timout error.
You can change the theme in settings => Switch to Truth theme. Everyone likes a dark theme
But this doesn’t explain why MySQL on InfinityFree is just as slow. Most of the posts are images here so I know that the antivars are going to hang it but it still doesn’t solve why here is slower too.
EDIT: The error on that line is an image on a post that wasn’t properly uploaded. I can ask that user to simply delete that post.
I’d be happy to provide the proof you’re looking for. What do you need me to show? To clarify, I’m not talking about sending requests to the server, I’m talking about manually editing table values on this site’s control panel without going to my own website.
I’m currently doing that. What I’m going to do is to run a PHP script to check if data is there first before calling it; I may have been injected. Thanks for the advice.
In addition, I’m blaming a module I have for being able to move the notifications box too. I think that’s where most of the scripts come from but still unsure. In the meantime I’m checking my js for anything.
A virtual currency is a TOS Violation? “Truth coins” is just a small on-site currency for name changes and stuff like that. I don’t see how that’s a bad thing.
That’s just an update for introducing it but I don’t see how it violates the ToS. You will need to at least quote or give some information as to what having a virtual currency violates.
EDIT 1: Also, are you saying that a website can’t have images? There’s more to it than just the pictures I believe because I can simply limit the number of images being posted. Like I said before, it’s not a social media platform, it’s just a small fanbase where I share my content.
EDIT 2: This also drives away from the point. When everyone’s just throwing faults at the site, I’m not really getting any information as to why when I go to InfinityFree, and go to MySQL, I can’t manually enter some data without waiting like 11 seconds before the request even begins to be sent out. Sure my website does have some issues but I’m not perfect and 100% of the slowness doesn’t just fall back here, because logging in here on this website doesn’t load my website now does it?
Of course not! Just that your website has too many of them.
Maybe you can consider limiting the number of posts/images per page to speed up the loading???
This is free hosting after all…
I don’t partake in Cryptocurrency. A virtual currency here would context to “on-site” currency and it’s non-transferrable and non-convertible. You can neither buy it with crypto, nor can you trade it for crypto. It’s also against the ToS on my site too and it leads to a permanent ban.
I’m thinking what you’re referring to is the image compression. If that’s the case then that’s a good idea if you want to stare at an 8-bit Mario game on-screen. But I can’t argue the point that limits are set on a free web hosting platform.
I’m one guy coding, and all updates come from me. So it’s basically my fault if anything code-wise goes wrong. As such, I will mark your reply as the solution.
IIRC phpMyAdmin tells you the execution time of a query. Can you share an example of a query and how much time it took in phpMyAdmin?
While the page size is quite high, a speed test also shows that the TTFB is ~7-10 seconds, which is very high.
I did take a quick look at your code, and I think there is also still a lot of optimization to be gained by optimizing how your query the database. I noticed locations where you were sending many queries to the same table to fetch different rows (which can be combined into a single query with the right where clause), using multiple queries to update different columns in the same table row (for EVERY request), and at least one case of an N+1 query (executing a database query within a loop for every item in the loop, which can load to explosively more queries to load a page as more items get added).
Most likely you’re referring to the theme control and notification queries, which are still experimental features currently being revised before official launch. There will be updates on those soon.
phpmyadmin does respond to queries in approximately 0.0011ms but the thing is not the difference between when the request is sent and received, but rather when the user presses Go and the request actually starts. I’ve noticed that an error is spat immediately when I tested invalid syntaxes and inexistent entries, but there’s this lengthy interval between when the user makes the request and the request is actually sent out.
The request starts immediately after you click go. I think you are getting some terms confused here.
It seems like it take a long time for the request to process because PHPMyAdmin has to send the query, then interpret the results. PHPMyAdmin is slow, the database is not. (PHPMyAdmin is a large application, and probably has hundreds of people using it at the same time).
The N+1 query is caused by the fact that for every post in the list, you run a query to check if the user is banned. So with more posts, you get more queries, which doesn’t scale well. And that’s not considering that you’re querying the same data repeatedly if a user has multiple posts.
And for every request, you update three columns in the users table, but you’re doing so with three separate update queries, instead of collecting the information first and updating the table only once.
And “experimental” or not, if the code is live on your site and is processing traffic, it will generate server activity. So if the experimental code is taking a lot of time to run, it will slow down your page load times.
And for most web applications, queries to external systems (including databases) are often the main bottleneck, so it really helps to make sure your query traffic is efficient.
That just sounds like clunky phpMyAdmin scripting. I’m betting that if you run the same query in Adminer, it will be very snappy.
I do this to avoid exploits so that they may not do certain things they’re not allowed to do, and possibly run something really heavy in an attempt to breach back onto the platform. I’ve also made it so that most events only occur onclick to save resources. All suggestions are welcome for optimizations, though I doubt this will get any due to the nature of the platform (it not being allowed to focus in or post code).
I’m not saying that it’s not causing some sort of heavy pull. Experimental features are almost never a nail hit but I’ve only been experiencing the slow request times after my .htaccess update. Even after removing a lot of features I still don’t see a change.
Total confusion here and my humblest apologies but are you pointing at the web browser being slow to react?
You didn’t appear to understand what I was referring to so I felt I needed to elaborate. I tried to be superficial, but I guess this was more detailed than it should be.
In any case, there is nothing wrong with having a system to ban users, and checking this on the post list. The problem arises when you run a query to check the user state for every post.
You can avoid this with a solution like this:
Retrieve the lists of posts as usual.
Iterate over the list of posts, building an array of user IDs that are in the current set of posts.
Run a single query on the banned users table, asking the database for a list of user IDs that match in the table, with a WHERE user_id IN (...) to only fetch the records of the relevant users.
Convert the result of the banned users list into an array of banned users IDs.
Iterate again of the list of posts. But instead of checking the user ID in the database, just look in the list of banned user IDs you already have in PHP if it’s present.
This way, the post list only requires two queries to be executed, regardless of the number of posts on the page. Otherwise, you execute 1 query plus the number of posts on the page, which can add up quickly.
Potentially, yes. Although I blame phpMyAdmin’s code more than I do how your browser or your computer runs it.
In the end, phpMyAdmin is basically just a website that queries your database. So like with a website, the Javascript code in the browser, and the PHP code on the server, affect browsing experience too. It’s not just the database.
That’s ok, everyone else did worse with the screenshots of the site, processes and its internal currency and I felt like I needed to divert from that without mentioning.
Might I say I love how you phrase your solution step by step. I can take this into consideration the first chance I get to get back to work. Thank you so much for your help.
