Quote:
Originally Posted by Shin Noir
At a glance, the system seems clean, but can be taxing on the database.. Could be nice to layer get_data() with a cache mechanic, similar to how rules work? Just a thought.
|
I already covered that here:
https://github.com/EQEmu/Server/wiki...ets#benchmarks
As long as you are properly setting an innodb_buffer_pool appropriate for your server, the query optimizer is going to handle the caching layer a majority of the time and read speeds are plenty suffice. When you can do 1,000 reads in .1-.2 seconds I would say that is plenty for any EQEmu use case
I also mention in this section that yeah we can further optimize on this but there is literally no point unless you are spamming reads/writes constantly every second at which case then you should probably be using something more in-memory temporary type storage such as entity variables
Quote:
Originally Posted by Scorpious2k
Is this a major performance improvement?
What does it do that qglobals don't?
|
While I have used qglobals a ton and they've been great most of the time, all of this heavy use has exposed many issues over the years
- Scaling Issues: On servers such as EZ that use Perl as its primary language, have serious performance issues when having a simple 4,000 global buckets sitting in the table. Every single time a sub routine gets triggered, it has to build that hash map of 4,000 hash values BEFORE it triggers the subroutine JUST so you can use the one value in your quest $qglobals{"value"} if at all. Not to mention if you have sub events that you use in say global_player.pl for example for special cast events such as EVENT_CAST. Anytime a player procs, it's triggering a sub routine which in turn would trigger a hash map to get built of 4,000 every, single, time. At which this would cascade the zone to hang for several seconds at a time to simply build an export that is used maybe if hardly at all. This paradigm is why the `perl_event_export_settings` table was built. See here: http://www.eqemulator.org/forums/sho...ight=footprint - This has lead to servers such as EZ and Stormhaven and several others to literally make their own storage solution in a custom Perl database plugin
- Frequent Use: Also, if you plan on using qglobals for anything even semi-intense, many times have I ran into issues where there is a race condition causes data loss in that bucket. If I am storing currency or values in this bucket, it becomes a problem quickly and it becomes hard to trace down unless you know how to read low level server code. The way we handle in memory updates and propagating updates to other zones via packets leaves room for non-atomic data storage issues to crop up. Running several servers I've seen this time and time again. You also see in many cases where a value gets set in one zone and does not properly propagate to another, having this new atomic solution should very much clear those issues up
- Ease of Use: From a server operator perspective and a person who supports most of this community, I've personally been burned by qglobals "not being turned on" in some context when used in multi-part scenarios. This is not friendly to new server operators and is simply not intuitive. Setting "modes" inside of a simple data set call (remembering numbers) is not untuitive when writing a script it should feel natural and not feel the need to pull up a web page to reference numbers and types and constantly have 4-5 arguments to set data when you just need to set 2, a key-value pair. So many times in Discord people are asking about qglobals and the issues they run into them, I decided that it was time to just put something quickly together. Simple key/value data set and get's should be atomic, easy, global and not explicitly contextual
qglobals by no means are being deprecated, there's just an alternative around which many should find useful and very solid
Hopefully that helps clear some questions up
A long overdue replacement for qglobals is live now!
~Shin Noir
Linear Mode
