Quote:Original post by sooner123

Quote:Original post by phresnel

Quote:Original post by sooner123
I am the server.

Huh?

Quote:I actually thought php scripts timed out after 30 or 60 seconds or something.

This is configurable. In theory, you can make that it never times out. In practice, it might depend on your hoster.

I am running the server.. on my own computer. I said that early on this thread but everyone seems to think I'm accessing a remote host.

If I disable timeouts.. it'll be disabled for anyone else accessing my server too?

I was hoping there was a command line argument to disable the timeout for that one call, but to leave the timeout active since it's an important feature.

you can pass a specific php.ini to the commandline, but...

Since what you really want to do is control the timeout on a per script basis the easiest solution is to call:
set_time_limit(0);
from the php script itself and then only run that php script from the cli.

As for running your own server, its something most of us do while we develop stuff (And i atleast assumed it was only for development purposes in your case aswell), most switch to external hosting services to get better uptime and reliability once the project is ready to be deployed (or as it grows in scale), alot of isps also won't allow you to run commercial services on their connections (Which pretty much removes your ability to generate revenue).

Quote:Original post by SimonForsman
set_time_limit(0);
from the php script itself and then only run that php script from the cli.

This does not work in safe mode, though. Also, are you sure you can override the php.ini's max-execution-time to a larger time, if set?

Hey there. Stumbled by, and thought I would show this topic some love.

From a performance standpoint, in your typical PHP+MySQL web application, updating the game state on demand is an extremely bad idea, on par with holding a metal pole in a thunderstorm or bathing in shark-infested waters with a bathing suit made of fresh seal meat. You can try it, and you can make it work (if your server is hideously over-powered for the number of users you have), but it has severe scaling issues.

The first problem with on-demand updates has already been mentioned: it might take a while between sessions. The next user to come online has to suffer a huge performance hit to let the game server catch up with the current state. Not because the language is slow or because it's doing a+=1 five times instead of a+=5 once (all of this can be optimized, although not necessarily for free) but because a massively concurrent web application needs to save the data back to the database, and writing data to MySQL is insanely expensive. If your application has to perform even one indexed INSERT per interaction, then a single user catching up on all the interactions for an hour of idle time will have one hell of a wait time. And without one INSERT per interaction, good luck implementing the «here's what happened while you were away» feature on your game.

But that's not the worst issue (you can kind-of-solve-it by making sure someone requests an update every X seconds, just like the Original Poster is trying to solve it here).

The second problem with on-demand updates is stampeding (or serialization, depending on how you look at it). Stampeding basically happens like this:

• User A connects to the server, notices that some updates should be done, and starts performing them transactionally.


• User B connects to the server. Since User A is acting transactionally, User B sees the same needs-to-be-updated game state and starts updating it transactionally. This doubles the performance load of the update.


• More users connect. Since the performance load increased, the updates take longer, so there's a higher probability of starting an upload that is already being processed. The server load increases until it basically gives up and takes its own life in frustration (yes, MySQL does that).

Depending on what your updates look like and how your transaction isolation level is configured, you might experience serialization instead: User A connects and does an update. User B connects and reads the "Todo" table(s) but is locked out because User A is working on it, so User B idles until User A is done. The lock on the "Todo" table(s) means your server can now only serve one user at a time. This is a major performance problem if you intend to serve more than a handful of simultaneous users, because locking problems can not be solved by adding more hardware.

The ideal architecture for a web game is to have a single update "thread" (might be a cron job or a script running without a time limit) that polls the database for things to be done and does them, and any number of threads to serve the HTTP requests from the players by reading data from the database and using lock-free, possibly delayed, cluster-indexed INSERTs to tell the update thread what to do. If you have the money, replicate the main database on another server and have all the players read from the slave to lighten the load and read locks on the master (if the server holding the update thread is powerful enough, you can scale your game to infinity). If you don't have that kind of money, and you see the update thread getting locked out too often, you might want to set lower a thread isolation level (READ COMMITTED) to reduce that (at the cost of sometimes displaying some inconsistent data on the user's screens).

In practice, it also helps if the game is designed so that most updates cost nothing. This can be done with two techniques:

• Do not compute or store anything the game logic does not need. If you don't need it to run the game logic, then you can compute it on demand when (and if) the user asks to see it and discard it afterward. For instance, if your units gain ranks based on the number of enemies they kill, then you do need to compute and store the number of kills, but you don't have to find out the name of the current rank until the user needs to see it.


• Use "do not open until" timestamps. Instead of the user inserting a "Build Space Station" order in an order table, they should instead insert a "Space Station" building in the building table with a timestamp of NOW() + buildtime. This means the act of successfully building the space station does not involve any computation (at the cost of an additional timestamp test when reading from the building table, but that can be easily indexed).

These will decrease the load on your server.

By the way, the default time limit for a PHP script running in CLI is infinite (and defaults to 30 seconds for CGI and Apache mod_php), so you don't have to configure anything.

[Note: I'm not a PHP guy, so my response may not be applicable]
I think people trying to develop persistent games in ASP/PHP.ASP.net often miss the mark because they do not separate game logic from presentation logic. These 'languages' are scripting languages used to generate dynamic HTML. Sure you can use them to also do simple work, but in a moderately complex persistent game, you need to have a dedicated persistent engine running outside the confines of these languages.

Sure you can do simple persistent games (like those Facebook type games or Conquer-Club where events are very timed or user initiated), however in persistent games where there are self-sustaining/controlled NPCs and game triggered events that require no user interaction, ASP/PHP/ASP.net is a poor choice. I don't know about PHP, but ASP.net has support for multi-threading, but even that is a poor way of implementing a persistent engine.

You need to approach game development like you would approach any other application development. In proper application development, you should separate your business logic (or in this case, game logic) from the presentation. With that approach in mind, any ASP/PHP/ASP.NET developer should see PHP has the means of presenting the state of the game to the user, not the game itself. You should develop the game using a different technology that can run continuously in its own process space.

The trick comes in when you want your presentation layer to communicate with your logic layer. This can be done through a few different means:
- Game engine saves the game state to a persistent medium (i.e. a Database) for read-only retrieval from the presentation layer. Actions are sent to the engine through a channel such as a queue table that the game engine pings for actions to perform.
- Any presentation layer communicates with the game logic through the use of a custom protocol over a TCP socket. The HTTP request comes in, it opens a connection to the engine server, sends the action to the server, the server sends some sort of response, the presentation layer takes that response and presents it back to the user.

Both of these implementations, in my opinion, are better than trying to hack PHP/ASP/ASP.net into doing something that it was never designed to do. You'll drive yourself crazy trying to implement something as simple as an Update/Heartbeat event when it can be done easily and quickly using another approach.