Performance loading the botnames from a cache

[hermensbas]

GenderRaceBotNames retrieved from a cache instead of using a DB call per name on a 100k record table 'playerbots_names'.
The name fallback is still in place but had to replace to IN_USE mechanism with a inner join. The IN_USE enforced cache still need to make the IN_USE db call which took a huge performance hit. Before 1-2 seconds per account creation, now a few seconds for 100's of accounts.

Tested with cache and without the cache enabled and with fallback mechanism active.

[Rozza122]

GenderRaceBotNames retrieved from a cache instead of using a DB call per name on a 100k record table 'playerbots_names'. The name fallback is still in place but had to replace to IN_USE mechanism with a inner join. The IN_USE enforced using the cache still to make a DB which took a huge performance hit. Before 1-2 seconds per account creation, now a few seconds for 100's of accounts.

Tested with cache and without the cache enabled with fallback mechanism active.

adding a new index to playerbots name increases speed slightly too:

time with no index 337ms~, with new index 58ms~.

Query ran:
SELECT n.name
FROM acore_characters.playerbots_names n
LEFT OUTER JOIN acore_characters.characters c ON c.name = n.name
WHERE c.guid IS NULL and n.gender = '8'
ORDER BY RAND() LIMIT 1;

New Index:
ALTER TABLE acore_characters.playerbots_names
ADD UNIQUE INDEX name(name, gender);

[hermensbas]

Good point, just in case when the fallback is being used and tiny bit faster when loading the cache. Also noticed i didnt cleanup the in_use from the playerbots_names.sql. Thanks :)