CtrlFreq

Re: [mccodes] 5 Card Draw [10$]   I mean, in five card draw, you get to discard and draw replacement cards. You're just showing cards.

Re: How do you make money from your game?   Our game is turn based, so we sell upgrades, which last 7 days and allow players to accrue faster, and bulk packs of turns, for those who are either impatient, or have a vendetta. Upgrades run $5 to $100, turn packs from $10 to $1000. Because of the distinct advantage these extra turns give players, we have three sets of prizes - one for free players, and two classes of paying players based on how much they've put in.

Re: [mccodes] 5 Card Draw [10$]   uh, your five card draw seems to be missing it's draw

Re: One Big Code!   while (true) { print ("this is the song that never ends...it goes on and on my friend..."); }   Whoops - broke the thread :evil:

Re: Password Recovery   No, because that would expose how we're salting, but here is the generic idea: First create a function:   function SaltPassword ($salt, $password) { $saltedpass = md5($salt . $password); return($saltedpass); }   This way when you commit a password to the database, you just commit it salted, and when users authenticate, you salt their input and compare against the hash, ie:   // Set the password $sql = "update users set password='" . SaltPassword($salt, $password) . "' where user_id=" . $sql_safe_user_id; // Authenticate $sql = "select user_id from users where username='" . $sql_safe_username . "' and password='" . SaltPassword($salt, $password) . "'";   Make sure your salt will always be the same per user (ie. use a substring of, or md5 hash of their username as the salt, and not something volatile like their IP address), and you'll be set. Since you're just generating a hash anyhow, it's no trouble to rip the string down to 15-20 characters, or otherwise modify the hash in your SaltPassword function to make it stronger, ie:   function SaltPassword ($salt, $password) { $saltedpass = substr(md5($salt . strrev($password) . md5($salt)), 5, 15); return($saltedpass); }

Re: Password Recovery   And that's the reason we salt our hashes :-D

Re: google and your game   We don't allow their bots to crawl the game directly, but we've made our persistent forums, and a number of other pages viewable to the public, and we link to them from our sitemap.xml file. It's constructed so it always reports the current time as last updated to google each time they catalog our site. For a bonus, it also has the effect of providing a number of hot links into the site when we're searched for on google.   <?PHP Header ( 'Content-type:text/xml' ); print('<?xml version="1.0" encoding="UTF-8"?>'); ?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>http://www.themobstergame.com/system/index</loc> <lastmod><?PHP print(date("Y-m-d") . "T" . date("H:i:s.0P")); ?></lastmod> <changefreq>always</changefreq> <priority>1.0</priority> </url> <url> <loc>http://www.themobstergame.com/system/forum</loc> <lastmod><?PHP print(date("Y-m-d") . "T" . date("H:i:s.0P")); ?></lastmod> <changefreq>always</changefreq> <priority>0.4</priority> </url> [other URL nodes with different priorities] </urlset> <?PHP die(); ?>

Re: MyIsam or InnoDB or ?   I'm the first to admit I'm still learning, and am always open to new information (great bit on the MyISAM file handlers btw). I've just been through the pain of having a table or two crater my game under load too many times to wish it on anyone else, especially when the performance hit on the low end is negligible.

Re: MyIsam or InnoDB or ?   Noone ever said MyISAM is inferior to InnoDB - hell, my game's database is comprised of about a 50/50 mixture based on the table's usage pattern. MyISAM is perfect for inserts and reads (ie. message boards, audit tables, bans, whitelists, upgrades), but it fails miserably under load on tables with high update and insert counts (players, resources, etc).   Of course not, which is why you devised such a pertinent set of test cases to prove your point. The real issue here isn't you, but rather the people who are reading, or are going to read, this thread thinking you've actually got a point because they don't have the experience necessary to spot the flaws in your test. If you want to keep advocating the use rocks to hammer in nails, by all means, keep it up. Just don't be surprised when people point out that hammers are more effective because they've been designed for the particular job at hand.

Re: MyIsam or InnoDB or ?   Why? Because good design is good design, and shouldn't be put off until an actual catastrophic event forces your hand. I understand the "it's not broke, don't fix it" mentality, but the corollary to that is "a stitch in time saves nine", and as the administrator of a web-based game, that means the difference between being prepared for load, and spending hours trying to figure out why your game was crushed under load after the event has passed (a position I've found myself in a number of times, and am actively trying to help others avoid).   The problem was your test wasn't valid for the hypothesis you were attempting to prove, and so your conclusion was based on faulty data. Sure, I could have just pointed out the size of the data-set, but that was only a third of the problem with your experiment, which is why I illustrated the others. It may have come across as being "more friendly", but it wouldn't have been more productive by any measure, nor would anyone reading this thread have learned anything of use from doing so.

Re: MyIsam or InnoDB or ?   Because 1) you're attempting to show a difference between engines, and 2) when your player table gets to be that size, it's only going to be the queries against that particular table that will be suffering, not to the periphery tables.   I've done this over the course of three years, including two years worth of production usage, during which I've experienced first-hand what I'm describing to you. It's all well and fine that your particular table performs better under MyISAM, but I'm pointing out that it's only because your data set is miniscule, and thus your test cases are inadequate to demonstrate the difference between storage engines, and the benefits provided by InnoDB.   Which queries block others is what this is all about - in fact, it's the very reason why InnoDB out-performs MyISAM so easily under load. The difference in an enterprise level environment is phenomenal, as it means the difference between being able to service a single write query (namely update and delete) to the exclusion of everything else and being able to service thousands reads and writes concurrently.   It is if it means the difference between your queries running and your server hanging at 100% CPU because you literally can't retrieve data from disk before the connection times out. I've watched a single MyISAM table with 10k records push an 8 CPU server with 16 gig of ram to 100% on multiple cores, every bit of which was due entirely to cpu wait (wa in top - waiting on I/O), simply because the queries on that table were blocking. In every case, a simple change of the table's storage engine from MyISAM to InnoDB has immediately alleviated the bottleneck and drastically improved performance.

Re: MyIsam or InnoDB or ?   The problem is your queries are all over the place and really don't give you an accurate indication of what you're looking for. Furthermore, you're only updating the table with 6k records using eqrefs, which means the delay from the InnoDB transaction log is going to slow you down more than the delay from MyISAM's full table lock. To get an accurate idea of the true performance difference, you need to change your test a bit... 1) up the number of player records to something beyond 25k - anything over about 12k should be adequate to observe slowness from MyISAM, but you're looking for real results, and 25k should do it. 2) get rid of any queries not dealing with the player table - you're testing a specific engine on a specific table, so the other queries you're running aren't pertinent to the test. If anything they're giving the table you're testing a reprieve between calls, which is tainting your results. 3) mimic an actual game session - meaning that you'll most likely do as many, if not more, updates to the table than reads. If you do these three things, you'll see the difference because the time to select will be exaggerated due to the wait for the MyISAM update locks to expire. Testing against InnoDB will not have said delay. Also, get a copy of MySQL Administrator from their site, and connect to the server - that way you can watch the queries as they hit, and you'll be able to see which are getting blocked in real time.

Re: MyIsam or InnoDB or ? How many records were in the table you were working with, and how many updates were you applying per cycle vs. selects per cycle? It just sounds like your test was drastically under the threshold required to observe the performance differences under load.

Re: InnoDB or MyISAM   Your test was wildly under the threshold required to observe the difference. As for testing, I can attest to the performance differences from more than a few years of production-level usage, during which my hand has been forced in an number of instances to move from MyISAM to InnoDB due entirely to performance issues. Simply put, when under load, MyISAM cannot compete with InnoDB on a table with a high number of updates because of it's locking mechanism. Try your test again, only populate your table with about 50-100k records, and do random updates while simultaneously running queries. The MyISAM table will get crushed because any read will have to wait for any updates that came before it to finish because MyISAM only supports full table-level locking. InnoDB, on the other hand, will keep going without even breathing hard due to it's ability to only lock the specific rows affected by the query. Also, grab a copy of MySQL Administrator, which lets you see specifically what is running against your database during your test - you'll be able to witness first hand the selects being blocked by the updates on the MyISAM table, but not on it's InnoDB counterpart.

Re: Question for all game owners We drop the two SCRIPT tags in just above the closing body tag. Since we're using smarty templates, and have a base page everything derives from, these only appear once in the code, but on every page of the site, so we get a fairly in-depth view of whats going on.

Re: InnoDB or MyISAM   Assuming that table is regularly updated, instead of just being inserted into, that's correct, InnoDB is a much better choice for the engine.

Re: Is there any? There are plenty of cheap ones, but like always, you get what you pay for...

Re: Another problem need help with   They were both two lines of code, the sprintf was just expanded for readability :-P

Re: SQL Injections   It's not so much that you were wrong as much as it was the fact that it was ultra-paranoid, buzzword-laden, and entirely incoherent.

Re: Simple MySQL optimization   In his example or mine? If mine, you've helped illustrate my point, as the brackets weren't unnecessary, as the bracketed query would return FAR fewer results due to the execution plan.

Re: Simple MySQL optimization   The problem is when it comes to overriding the order of operations purposely, which your advice could cause other people to subvert unintentionally in trying to "optimize" their code (especially given the audience you're sending this to). For example: WHERE ((bankmoney >= 0) OR (fedjail <= 0)) AND (last_login >= (UNIX_TIMESTAMP() - (3 * 86400)))) would return is entirely different (and drastically smaller) set of records than WHERE bankmoney >= 0 OR fedjail <= 0 AND last_login >= UNIX_TIMESTAMP() - 3 * 86400   That's the point though, people remember that parenthesis mean "do this first" if they remember nothing else from high-school math class, and if that makes it easier to understand, then that extra tiny bit of work mysql does is worth the legibility to both yourself and any other coders who may follow in your footsteps in spades. But then again, my game is only on the top of this site's top game list, so your mileage may vary.

Re: Another problem need help with   Your problem is because your list of items is being passed to sql as a single string. Make items an array and then implode it with a comma to make the list for your IN clause.   $items = array(61,62,63,64); $checkitems = sprintf ( "SELECT COUNT(`inv_id`) FROM inventory WHERE ((`inv_itemid` IN (%s) AND (`inv_userid` = '%u'))", implode(",", $items), abs(@intval($userid)) ); $items = $db->query($checkitems);

Re: Simple MySQL optimization   When it comes to I/O issues, that's always the case. If your queries start slowing down during peak load, and you've done what you can optimizing indexes, queries, and query plans, then your next plan of attack is anything to speed up I/O. We found that during our end-game routines, our player resource table was getting crushed due to disk speed - our first attempts were in the form of query optimizations, and then indexes. When these were no longer adequate, we moved on to separate spindles on faster disks (raid-1 mirrors on 15k SAS - one for logs, another for data - as is common practice). After these were shown to be too slow, we went to mounting our actual mysql file structure in memory via TEMPFS. Now, our db keeps up with whatever we toss at it, but we're currently in process of planning future upgrades in which we will be moving to clustered situation in which there are multiple read and read/write members, each with a specific partition of the database (ie required replica tables for particular activies), all running directly out of memory.

Re: InnoDB or MyISAM   We use a combination of each, depending on the use of the table, all in the same database. MyISAM is best for read/write tables, as reads don't lock, and InnoDB is best for tables with a lot of updates, as it allows for row-level locking and is transaction-safe. A scenario for each would be as follows: User and Player tables: use InnoDB, since you're going to be updating these records regularly during game-play. Audit/Log and Message tables: use MyISAM because you're going to be writing and reading from these tables, but rarely updating them (you may allow for messages to be deleted or moderated and such, but there are few updates expected)

Re: Simple MySQL optimization   I'd imagine you see it there because it's also in the high-end, professionally-authored code available in books and tutorials they've either learned or cut & paste from. The reason it's done is for readability, which is much more important overall than trying to optimize the already extremely tight order of operation handling mechanisms in mysql. If you're really wanting to optimize that particular process, there are some very real things you should be doing: First and foremost, the engine; is this table insert and read only, or are there updates? If there are updates, you should be creating the table using the InnoDB engine, which allows for row-level locking. Next, how many records are in the table? More than a couple thousand and your performance goes to hell unless you've got indexes in place, and THAT is where optimizations of the query, and the query plan really begin to matter. Beyond this, you get to the real meat of the issue, which is I/O speed (getting data to and from the disk), which is the real nemesis of DBAs everywhere.