Reducing Number of Pageloads

[Talisman]

I'm not sure whether this will help reduce the load on the system or not, but...

Does every page loaded run an SQL query to fill out any information, or do only certain pages run the query?

My idea should make a big difference if the answer to the foregoing is "yes", and might make a worthwhile difference even if the answer is "no".

It strikes me that there are a lot of unnecessary page generations/loads which could be reduced by adding a few more navigation options in the menus. As an example, when I'm playing Dice with the Old Man I'm usually there for more than one game. With the current setup, after each game it is necessary to return to the Inn (which has to reload darkhorse.php), then select "Talk to Old Man" followed by "Play Dice Game" (reloads oldmanbet.php).

Would it not reduce the demands on the server if there was a "Play again" choice, or even one to "Return to the Forest"? Play Again would reduce the number of pageloads by 2 for every game repeated, which I know would make a difference in my games.

I realize that some lengthy navigational routes must be maintained in order to maintain the mysteries of the game and exploration, but there are many where the number of pageloads could be reduced and theoretically reduce the server load.

[lonestrider]

I've just spoke with a couple of friends who've worked on some fairly impressive MMPG (massive multi player games) in the corporate sector about what we're tinkering here with in PHP.

After 20 minutes of looking at the code, the first thing they said was it must bottleneck at 40 players.

I give it more like 60. I agree and I really find that we're hitting the database in a very messy way and we're banging our heads against some serious technology limitations. I think that a lot can be solved by having some server-side includes and possibly caching some of this information. I think we could cut the database requests in half easily, possibly into a third just by cutting some of the unneeded requests from the script. I'd be afraid to do anything TOO major to this system for fear of forking WAY too far from the initial system.

Eventually, we'll probably have to look at bringing in some other technology. PHP was really made for static state pages, not active state and the limits of PHP are very near exceeded in the ability to scale it. It might be near time to consider a combo-technology using some java or something truly active to take the load off the server and give some more power to the technology.


Typically I don't gripe about what we're dealing with. The story is key and all important to me. ::Offers a puckish grin:: And since reality certainly isn't a tether that claims hold upon me, I'll plug along in this project however it goes so long as it holds my interest.

But there are some issues that we're hitting and we'll need to figure out soon.

[MightyE]

We've got an idea which simplifies down to splitting the user table in two, with public and private properties for the user (in reality, private properties don't exist as columns in a separate table, and are loaded on an as-needed basis). This will lift the database-side row locking difficulties which are the primary cause of bottlenecking, though not totally eliminate them.

If this were a continuous connection environment like many (any other?) mmorpgs, we could have a lot of control over when a user saves, and only make the save actually write to the database when some public property of the user has actually updated. Since it's not a continuous connection environment, we can't tell when a user has "gone away," and so we can't simply hold their information in ram or their session, and so we must write it to the database on each page hit. The table split idea will lighten the length of the row lock, which will reduce the blocking particularly in areas such as comment areas, but it won't eliminate it entirely.

We *do* have to write the entire state of the user's environment to the database on each page hit since they really do go away at the end of each of these hits, and this comes with the terrible performance hit that we see happening on lotgd.net.

This cannot happen until I have sufficient time to work on it though, which isn't right now.

Any specific suggestions are *far* more than welcome, we're planning on a major restructuring of the underlying database, and we'd be happy to hear ideas before we go to this effort.

[Arachnid]

Yes, I realise this post is a few months old, but perusing the forums I haven't seen any solutions proposed...

Eventually, we'll probably have to look at bringing in some other technology. PHP was really made for static state pages, not active state and the limits of PHP are very near exceeded in the ability to scale it. It might be near time to consider a combo-technology using some java or something truly active to take the load off the server and give some more power to the technology.

Excuse me, but what on earth are you talking about? PHP is designed from the ground up as a server-side scripting language for creating completely interactive and content/user driven pages. The interpreted nature makes it slower in some respects than other things, though pseudo-compilation and optimisation (as provided by the Zend suites) can make a difference there. Besides that, what exactly makes it "made for static state pages"?

On to positive suggestions...
Do you really need to save the entire user's state to the DB on each query? First, can't you check to see if any user data has actually changed before updating? (checking against session variables or setting a flag in code that changes it, rather than checking it against the DB). Second, do you need to (in fact, do you at all) save data that would expire when the user times out? Can't you store all session-specific data in the session variables, then simply return the user to the town square if they time out? (I realise this has gameplay issues).
Caching query results in the session variable seems like it could be a good idea to reduce DB queries for other categories, too, where possible.

Also on the topic of server load reduction: Page load times and server bandwidth could be reduced substantially if the themes used CSS as it is intended - embed width/color/height/etc and all other formatting properties in the CSS file instead of the HTML - this is both cleaner stylistically, as well as making it easier to change layout and styles, and reducing load, as the browser won't reload the CSS each page-load. The same applies to shifting large chunks of javascript into seperate .js files that are linked in.

More drastic than that, it might be worth considering the use of Smarty (smarty.php.net), a PHP templating engine, which allows templates to be compiled, and generated templates to be cached, where appropriate. This would also make themes easier to write and maintain.