Go Back   EQEmulator Home > EQEmulator Forums > General > General::News

General::News EQemu news posts.

Reply
 
Thread Tools Display Modes
  #1  
Old 07-08-2018, 04:21 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,072
Default A long overdue replacement for qglobals is live now!

See for more info https://github.com/EQEmu/Server/wiki/Data-Buckets

Commit: https://github.com/EQEmu/Server/commit/41ab512
Reply With Quote
  #2  
Old 07-08-2018, 09:16 PM
ChaosSlayerZ's Avatar
ChaosSlayerZ
Demi-God
 
Join Date: Mar 2009
Location: Umm
Posts: 1,492
Default

Amazing, A++ work!
Reply With Quote
  #3  
Old 07-09-2018, 06:31 AM
Scorpious2k's Avatar
Scorpious2k
Demi-God
 
Join Date: Mar 2003
Location: USA
Posts: 1,067
Default

Is this a major performance improvement?

What does it do that qglobals don't?
__________________
Maybe I should try making one of these servers...
Reply With Quote
  #4  
Old 07-09-2018, 11:45 AM
Shin Noir's Avatar
Shin Noir
Legendary Member
 
Join Date: Apr 2002
Location: Seattle, WA
Posts: 506
Default

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.
__________________

~Shin Noir
DungeonEQ.com
Reply With Quote
  #5  
Old 07-09-2018, 03:21 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,072
Default

Quote:
Originally Posted by Shin Noir View Post
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 View Post
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
  1. 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
  2. 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
  3. 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

Last edited by Akkadius; 07-09-2018 at 03:28 PM..
Reply With Quote
  #6  
Old 07-10-2018, 12:16 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,072
Default

Per requests, I added shorthand time methods that are documented here:

https://github.com/EQEmu/Server/wiki...e-time-formats
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On

Forum Jump

   

All times are GMT -4. The time now is 01:34 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3