Your account was suspended because you hit the Entry Process limits."
Other Information
This problem has occurred at least 2 times for what I think it’s a bot attack. My web is just an interface I developed to make my friends’ D&D game easier and more fun to play, which is the reason why we are just around 10 users, who also don’t enter so often in the site. I don’t think the reason for hitting the Entry Process limits is us overloading the web, because apart from the fact of us being a very small group, these errors come as too many petitions in a very punctual moment, as it can be seen in the screenshot.
I would like to have a confirmation of this error being caused by bots or not, and if so, if there’s something I can do against them, even if I have to code a js/php solution for it.
We have no way to tell, unfortunately. What you see in the graph is basically the extent of data we record. We don’t store full server access logs you can use to analyze the traffic of your site.
It could be caused by bots, or by legitimate users. It’s interesting that while your hits usage and entry process usage correlate, the hits usage is still very low, which could indicate that the entry process usage is caused by a short burst of traffic, rather than continuous load.
This could also be the result of your website itself, not the traffic. For example, if you have Javascript code that constantly and rapidly refreshes data in the background, you’ll very quickly run into the entry process limit, even with only a few concurrent users.
I have already read that and, for each one of the possible solutions this happens:
“Ensure static files (like HTML or CSS files) don’t have the .php file extension. All requests to files with the .php extension generate entry processes, even if there is no actual PHP code in the file.”
-I can’t use static files as the web checks if the user is an administrator before rendering the content
“Reduce usage of AJAX and other background requests. If your website has code that constantly refreshes the page in the background (to check for changes or new messages), this can easily cause high entry process usage with few visitors.”
-Ajax is used, but the data doesn’t get refreshed until the user makes an action which changes the database, so it’s not a real time app which constantly refreshes data
Added to the fact of ajax not refreshing data constantly, the data is only updated for the user who has done the change to the database and not the rest of users. While the user who has made the change will have an updated version of the page, the rest of them will have an older one, until they refresh the page or update the database
I’m sorry, but nothing like that exists. PHP just executes the code you tell it to run, it doesn’t have a management panel that records all code that is being executed.
Entry processes just tracks the number of active processes for your account. For free hosting, the data you see in the graph is the extent of the data we have.
For premium hosting, the information is more detailed: you can see when during the day the usage happened, and see resource snapshots showing which processes were running. But those only tell you that a web request is running, it doesn’t say anything about which page was requested, let alone what the code is doing.
Here’s how I think I solved the issue, but I think that only time will show the truth:
The first time someone got into my page, all the data was loaded. That was not a big problem, as it’s a new web and it doesn’t have much. The problem was in HOW I was getting that data. The data was obviously from different tables, with a structure like the next one:
Dice
Users
NPCs
Items
Documents
Jobs
Missions
Abilities
Maps
Battles
Events
As you can see, there are lots of different types of data. Well, the way I got that data was by chaining promises, which sends a petition each time. Obviously, every time someone accessed or refreshed, 11 petitions were made, and if the user is impatient and refreshes it 5 times, we get to 55 petitions in no time, which is a lot.
How I solved this was by creating an object which wraps all the objects in php and sending it to js in only one petition just for then splicing that macroobject in the client side.
