Quote:

Original post by Anonymous Poster Finally, I still suggest using a very slow machine for the DB if you intend to use one. The distributed nature and latency issues caused by the slower machine, tend to help you:

actually, i plan on keeping the DB on the same machine as the game is running. this way no bandwith is used and acessing the DB is faster.

Quote:

1. Identify blocking issues early on. This is a common problem caused by making the assumption that you shoot off a DB request and sometime later "assume" that the data is ready to be used when it is actually still waiting. Good architecture can prevent this most of the time but getting to that point is the first worry.

you know, i guess i really dont know how much the inner workings of the MySQL C API work. however, i was assuming that when i called an update statement that the change was made as soon as i called the function Run_Querey("update table ..."). so then you dont think this is guarenteed to happen?

Quote:

One last item to mention. I don't suggest Linux as the starting point for the server *if* the client is going to be Win32. This is not meant to offend the Linux folks it is just a point of opinion. If you are writing a Win32 client with VC and have the server running under VC, you have a lot more flexibility in remote debugging options than you do with mixed OS's. This just simplifies life at the start, later you can port over to Linux, while not simple it's not devastatingly hard, but a single debugging framework helps significantly up front while building up the architecture.

thats actually a good idea. however the client IS planned on being cross platform. in fact, one of the reasons i wanted to use Linux was so i could compile the client on the server box since i dont want to dual boot my laptop. however i could always just port the client over at the last minute. i guess i thought that it would be easier to start porting sooner then later (im already 10 months into development and havent tried porting yet). i use all cross platform libraries and dont think i have any windows specific code in the game.

[Edited by - graveyard filla on January 31, 2005 1:49:46 PM]

Quote:

i was assuming that when i called an update statement that the change was made as soon as i called the function Run_Querey("update table ..."). so then you dont think this is guarenteed to happen?

Chances are, the DB API itself is using a socket to connect to the DB server. So no, it isn't guaranteed to happen right away, and if there's no concept of 'store and forward' implemented, then it's not guaranteed to happen at all. In best case scenarios, you can reasonably assume the data will update in a timely manner, however please note the keywords "reasonably assume" and "timely" which are variables according to your own code and requirements expectations.

Quote:

i was assuming that when i called an update statement that the change was made as soon as i called the function Run_Querey("update table ..."). so then you dont think this is guarenteed to happen?

If the command that completes ends in a "commit" then, yes, when the function returns you will know that any updates you made are globally visible. Before and unless you execute the commit, there are no guarantees one way or the other, except the guarantee that nobody else will see the changes until you commit, if you've started with a "begin transaction".

Quote:

MicroATX

Some MicroATX cases have issues with power and heat management, if you're going to try to push big fat CPUs and graphics cards into them. You aren't. Also, MicroATX has fewer slots, so there's less room for expansion through PCI -- which doesn't matter to your setup.

Quote:

You can write extremely simple valid looking code which will execute perfectly on a single CPU machine but fail 1 in 10 times on a real SMP machine.

What I learned from my OS work: If your application fails on SMP machines, you will fail on UP machines too. If you don't, then you're not stressing your UP machine enough. Try recording audio, playing back a video, encoding an MP3 and downloading a large file from a local file server while running your program for an initial set of well-dispersed load (interrupt rate, network, hard disk, CPU, etc).

I wholeheartedly agree on artificially slowing down parts of the system to look for scalability issues; it's a tried-and-true technique.

i actually have never personally used the comit command or explicitly commited anything. am i supposed to do that? im assuming that the query browser program and the MySQL++ API must do this for me, since my DB seems to be intact after rebooting my computer many times [grin].

If you execute code outside of a commit, the specifics about when/how it gets committed is left to the API. It may be that MySQL implicitly puts each statement in a commit, and the commit has happened when the API function returns -- that would be conservative, and a little bit slow. Check the reference manual to make sure.

I would structure things to use explicit transactions -- typically, that's higher performance anyway, if you can make a bunch of changes and then commit at the end, in addition to being an atomic set of changes.

I'd also like to point out something- since you're running on a cable connection, ISP's (at least mine) usually get mad at you if you run a server, unless you buy a special "business package" or something like that. Also, it will probably be pretty annoying to have a dynamic IP.

kman12