forums.smartfoxserver.com

This is more of a best practices question as oppose to a how to question, as I can think of several off hand.

I'm adding critical change and critical bonus to "spells" which are just MMOItems. Currently the player sends a request for the Spell, the server pulls the data from the database table (damage, speed, damage range, cast time), the player runs a casting timer function and sends the request to instantiate the spell to the sever, and the server instantiates it.

What are the drawbacks/ advantages of these options:

1) When the player sends the request to instantiate the spell to the sever, he has already ran a function to determine if the spell is going to be critical and sends over the request with the critical damage already added to the spell.

I feel like this would be the easiest, but leaves allot open to the client.

2) When the player sends the request to instantiate the spell to the sever, the sever determines if the spell is critical through a function and could receive the critical bonus and critical chance from the proper database table.

This way seems more secure but could have some lag or scaling problems I'm thinking. Would having so many calls to the database cause problems when scaling?



I'm sure that there are a couple more ways so I'm open to ideas on what would be a good balance of security and speed.

Hi,
yes hitting the database very often is likely to cause scalability issues because your request will not run in a few nanoseconds on the server side, instead there will be a call to the database which goes through the network and comes back, requiring at lest a dozen milliseconds.

This in turn will increase the number of threads necessary to run many hundreds of those requests at the same time... etc...

This seems a scenario where a good DB cache would help a lot. I would imagine that the number of available spells is not going to be enormous right? 50? 100?
In any case a simple cache would make a good solution to avoid hitting the DB too often.

Hope it helps

Lapo wrote:Hi,
yes hitting the database very often is likely to cause scalability issues because your request will not run in a few nanoseconds on the server side, instead there will be a call to the database which goes through the network and comes back, requiring at lest a dozen milliseconds.

This in turn will increase the number of threads necessary to run many hundreds of those requests at the same time... etc...

This seems a scenario where a good DB cache would help a lot. I would imagine that the number of available spells is not going to be enormous right? 50? 100?
In any case a simple cache would make a good solution to avoid hitting the DB too often.

Hope it helps

I was noticing some lag on replies when working on a character save function which has several DB request, though that was all on my local dev rig which hoses the server, test, DB and client so I thought it may have just been too much work for my tower. The available number of spells and creatures will start around the 100-150 range but maybe go up to 300 or 400 in total.

I will start looking into some cache solutions. Any suggestions? My "production" server is running CentOS and MySQL and my dev/test rig is windows 7 based.

Well ok, 300-400 is still a manageable number.
Are these spells and creatures going to change often during the game? I suppose they shouldn't, right? Their properties are fixed during the course of the game?

If that's the case you could even just load them all in memory when the server starts up and avoid wasting time calling the DB layer every time to read those values. Unless each item has an ungodly number of properties we're just talking about 400 objects in memory, it's no big deal. But performance-wise it's a major step up.

Mysql caches? There's many options, memcached is a popular one. But you may also want to look into ORMs such as Hibernate or EclipseLink, which provide caching and a higher level abstraction of your data.

cheers