PHP working with concurrency

Question

I am running an enterprise-level PHP application. This is a browser game with thousands of Internet users on the infrastructure, which my boss refuses to update, and the equipment runs on 2-3 system load (yep linux) at any time. In any case, this is not a real problem. The real problem is that some users are waiting for the server to load (in prime time), and they bring their mouse clicks, and they press the same submit button as 10-20 times, while sending 10-20 requests while the server is still creating the initial request, thereby not updating the cache and database.

I currently have an output variable for each request that is valid for 2 minutes, and I have a mutex lock, which is basically a flag inside memcache, which, if found, blocks script execution further, but the mouse clicker does there are so many requests at the same time that they work almost simultaneously, which is a big problem for me.

As you, most people at StackOverflow deal with this issue. I was thinking about flagging a cookie / session, but I think I will get into the same problem if the server is overloaded. Optimization is impossible, the source is 7 years old and quite optimized, without querying on most pages (disabling cache) and only querying the database for a specific user input, like the one I'm trying to prevent.

Yes, this is procedural code without real objects. The machines run PHP 5, but the code itself is more connected with PHP 4. I know that I know this old and other things, but we cannot save the resource from overwriting all this mess, since most of the original developers left it to know how the material is interwoven and yes, I mostly fix old holes. But as far as I know, this is a common problem on loaded PHP sites.

PS: Disabling a button from javascript to submit is not an option. Real cheaters are advanced users. One of them wrote a bot clicker and packaged it as a Google Chrome extension. Do not ask how I dealt with this.

Answer 1

I would be looking for a solution outside of your code.

I don’t know which server you are using, but apache has some modules, for example mod_evasive.

You can also limit the number of connections per second from the IP address in your firewall

Answer 2

I get the feeling that this is more about updating an outdated code base than anything else. When implementing any type of concurrency, it would be nice, the old code base is a real problem.

I highly recommend this video that discusses Tech Debt.

Observe this, then if you have not done so already, explain to your boss in business terms that it is a technical duty . He probably understands this. Explain that since the code is poorly managed (debt paid), there is a very high level of technical debt. Suggest to him / her how to solve this problem using small incremental iterations to improve the situation.

Answer 3

restricting IP connections will only make your players angry. I fixed and rewrote a lot of things in some well-known open source cloners with the old style code: well, I have to say that cheating can always avoid doing the right queries and logic. for example, look here http://www.xgproyect.net/2-9-x-fixes/9407-2-9-9-cheat-buildings-page.html

In any case, about performance, keep in mind that the code inside the sessions blocks all other threads until the current one is closed. Therefore, be careful to pin all your code inside sessions. In addition, sessions should never contain heavy data.

About scripts: in my games I have a php module that automatically rewrites links, adding a random identifier stored in the database, a kind of CSRF protection. The user will click on the changed link, so they will not see the changes, but the scripts will try to request the old link and after some attempt there are prohibited! Other scripts use the DOM, so it's easy to avoid inserting some useless DIV around the page.

edit: you can grow your application with https://github.com/facebook/hiphop-php/wiki

Answer 4

I don’t know if there is already an implementation there, but I am writing a cache server that is responsible for filling cache misses. This approach may work well in this scenario.

Basically, you need a mechanism to mark the cache while waiting for a miss; reading the expected value should make the client sleep a small but random amount of time and try again; the collection of pending data in the traditional model will be performed by the client, faced with a skip, rather than pending.

In this context, a script is a client, not a browser.