Upcoming changes

[Splorf22]

I don't think anyone is claiming you haven't done a fantastic job.

We just wish you'd stop playing star wars and come back to it [You must be logged in to view images. Log in or Register.]

[Colgate]

can we get a confirmation on what color said text will be?

[Colgate]

Originally Posted by Colgate [You must be logged in to view images. Log in or Register.]

can we get a confirmation on what color said text will be?

[Smedy]

Rumor is orange

[Rogean]

Guy thinks hes gods gift to programming flashing his college degree around and still doesn't know shit about efficient coding.

[GODPARTICLE]

So what are you storing in if not a database?

Also I am a performance stickler, a fucking MyISAM read is not a bottleneck rofl

[Rogean]

Originally Posted by GODPARTICLE [You must be logged in to view images. Log in or Register.]

So what are you storing in if not a database?

Also I am a performance stickler, a fucking MyISAM read is not a bottleneck rofl

Anything that locks up the process waiting for a response from a different service, even if it's just an ACK from a database insert, is a bottleneck. What happens if the database query gets lock queued (because that does happen from time to time with 1k users online). There's a reason removing the bulk of on-demand SQL Queries from zoneprocess improved our stability tremendously.

You're thinking strictly from a database model point of view. What you need to consider is everything else that goes on including the code in the zone process itself handling all the database code, the transport code, and then the WAITING it does. You shouldn't have to fucking WAIT for a database to go "Herr ok I inserted it" before resuming code execution on an UPDATE/INSERT. (And yes, you still get the same problem with INSERT DELAYED, although only slightly improved).

[Gongshow]

[You must be logged in to view images. Log in or Register.]

[Splorf22]

Originally Posted by Rogean [You must be logged in to view images. Log in or Register.]

Anything that locks up the process waiting for a response from a different service, even if it's just an ACK from a database insert, is a bottleneck. What happens if the database query gets lock queued (because that does happen from time to time with 1k users online). There's a reason removing the bulk of on-demand SQL Queries from zoneprocess improved our stability tremendously.

You're thinking strictly from a database model point of view. What you need to consider is everything else that goes on including the code in the zone process itself handling all the database code, the transport code, and then the WAITING it does. You shouldn't have to fucking WAIT for a database to go "Herr ok I inserted it" before resuming code execution on an UPDATE/INSERT. (And yes, you still get the same problem with INSERT DELAYED, although only slightly improved).

100% agree that a database call is way more of an issue on a realtime game server than a webpage. I guess if I had to do it I would

a) Load all the info out of the database on server start/player login
b) Just have a simple write to 'the big logfile' (just copy the structs directly out of memory) so very fast
c) Have another process/thread which stuffs things into the database (If you want to make any sort of queries you'll have to either use a database or reinvent the wheel)

But I wouldn't be super happy with this, because I'd be giving up reliability. From what little I remember there is no way for the server to confirm that the logfile was actually flushed to disk before confirming the trade with the user AFAIK without using the very slow fsync call, so we aren't exactly talking banking level reliability here.

Kind of curious exactly what you did now [You must be logged in to view images. Log in or Register.]

[Rogean]

Originally Posted by Splorf22 [You must be logged in to view images. Log in or Register.]

c) Have another process/thread which stuffs things into the database (If you want to make any sort of queries you'll have to either use a database or reinvent the wheel)

/clap