Go Back   EQEmulator Home > EQEmulator Forums > General > General::Server Discussion

General::Server Discussion Discussion about emulator servers.
Do not post support topics here.

Reply
 
Thread Tools Display Modes
  #1  
Old 11-01-2015, 10:33 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,071
Default Perl Footprint Adjustment

I wanted to make a post to create awareness around the last commit I made regarding Perl. It really shouldn't change any existing functionality but only improve performance (exponentially) and I wanted to let people know why these changes were made and what for.

In summary: When Perl triggers a sub event, it goes through calculating and exporting quite a few variables at runtime and this can pose performance issues as your server starts to grow and events are triggered constantly. This does not pose an issue at all on LUA because LUA does not export things at runtime all the time, why would you when you don't use 95% of the variables most of the time in a given sub event.

- That is the reason why you would use "GetThing()" versus using $getthing, GetThing() is going to get that when it needs it versus $getthing is getting created regardless whether or not you use it in a script, times that by a few thousand variables depending on your scenario and it really starts to pose overhead issues.

- Item variables get exported in every single subroutine but they are only used in EVENT_ITEM and EVENT_SAY and maybe a few other rare sub events that I found on PEQ quest repository (that are turned on in the default table provided).

- If anyone has any questions regarding any of this let me know, I've ran it on EZ and seen substantial improvement. All of the notes are below.

https://github.com/EQEmu/Server/comm...a6a9280fcaf543

From Changelog:

Code:
Akkadius: Added Perl Export Settings which should heavily reduce the Perl footprint
	- Normally when any sub EVENT_ gets triggered, all kinds of variables have to get exported every single time an event is triggered and 
		this can make Perl very slow when events are triggered constantly
			- The two most taxing variable exports are the item variables ($itemcount{} $hasitem{} $oncursor{}) and qglobals ($qglobals{})
			- qglobals can pose to be an issue quickly when global qglobals build up, it is highly recommend to use the GetGlobal() and SetGlobal()
				methods instead as they don't reference the hashmap $qglobals{} that is rebuilt every single time a sub event is triggered
	- A stress test conducted with 10,000 samples shows an excess of time taken to export variables: http://i.imgur.com/NEpW1tS.png
	- After the Perl Export Settings table is implemented, and all exports are shut off you see the following test result:
		http://i.imgur.com/Du5hth9.png
	- The difference of eliminating uneeded exports brings the overhead and footprint of 10,000 triggers from 54 seconds to 2 seconds
	- In a 10,000 sample test (10,000 sub event triggers), exporting item variables adds 12 seconds alone, when item variables are only needed in
		EVENT_ITEM and EVENT_SAY a majority of the time if at all
	- In a 10,000 sample test (10,000 sub event triggers), exporting qglobals with approximately 1,000 global qglobals in the database creates
		about 11-20 seconds of delay on its own (Depending on hardware of course)
	- I've written a parser that has determined which of these exports are needed in which sub routines and have turned off all of the unneeded
		exports in sub routines that do not need them and used it to create the default table that will be installed in the database.
	- The export table is called 'perl_event_export_settings' and it resembles the following structure and contains all current 81 EVENTS
		- If an entry doesn't exist in this table and a new subroutine is added to the source, all exports will be on by default for that routine

	+----------+-----------------------------------------+-----------------+------------+-------------+-------------+--------------+
	| event_id | event_description                       | export_qglobals | export_mob | export_zone | export_item | export_event |
	+----------+-----------------------------------------+-----------------+------------+-------------+-------------+--------------+
	|        0 | EVENT_SAY                               |               1 |          1 |           1 |           1 |            1 |
	|        1 | EVENT_ITEM                              |               1 |          1 |           1 |           0 |            1 |
	|        2 | EVENT_DEATH                             |               1 |          1 |           1 |           0 |            1 |
	|        3 | EVENT_SPAWN                             |               1 |          1 |           1 |           0 |            1 |
	|        4 | EVENT_ATTACK                            |               0 |          1 |           1 |           0 |            1 |
	|        5 | EVENT_COMBAT                            |               1 |          1 |           1 |           0 |            1 |
	+----------+-----------------------------------------+-----------------+------------+-------------+-------------+--------------+
	
	- If a change is made to this table while the server is live and running, you can hot reload all zone process settings via:
		#reloadperlexportsettings
	- For those who wonder what "exports" are, they are reference to variables that are made available at runtime of the sub event, such as:
		(export_qglobals) (Heavy) : $qglobals https://github.com/EQEmu/Server/blob...arser.cpp#L916
		(export_item) (Heavy) : $itemcount{} $hasitem{} $oncursor{} https://github.com/EQEmu/Server/blob...rser.cpp#L1103
		(export_zone) : $zoneid, $instanceid, $zoneln etc. https://github.com/EQEmu/Server/blob...rser.cpp#L1083
		(export_mob) : $x, $y, $z, $h, $hpratio etc. https://github.com/EQEmu/Server/blob...rser.cpp#L1032
		(export_event) : (event specific) IE: EVENT_SAY ($text) https://github.com/EQEmu/Server/blob...rser.cpp#L1141
Reply With Quote
  #2  
Old 11-02-2015, 09:56 AM
provocating's Avatar
provocating
Demi-God
 
Join Date: Nov 2007
Posts: 2,175
Default

I have intentionally been trying to do all of my quest using LUA, as I create new ones. I know there has been a push to go more LUA.
Reply With Quote
  #3  
Old 11-02-2015, 12:07 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,071
Default

Quote:
Originally Posted by provocating View Post
I have intentionally been trying to do all of my quest using LUA, as I create new ones. I know there has been a push to go more LUA.
Really it's preferential at this point. This is a huge gain for Perl though in terms of its overhead
Reply With Quote
  #4  
Old 11-02-2015, 04:54 PM
chrsschb's Avatar
chrsschb
Dragon
 
Join Date: Nov 2008
Location: GA
Posts: 905
Default

Quote:
Originally Posted by Akkadius View Post
Really it's preferential at this point. This is a huge gain for Perl though in terms of its overhead
Appreciate the work Akkadius. I definitely prefer Perl.
__________________
Clumsy's World: Resurgence
Clumsy's World [2006-2012]
Reply With Quote
  #5  
Old 11-02-2015, 04:58 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,071
Default

Quote:
Originally Posted by chrsschb View Post
Appreciate the work Akkadius. I definitely prefer Perl.
Absolutely, it is quite the beautiful change in terms of overhead, virtually eliminating it. When you can make 10,000 subroutine triggers in 2 seconds that is extremely lean
Reply With Quote
  #6  
Old 11-02-2015, 05:51 PM
Shendare
Dragon
 
Join Date: Apr 2009
Location: California
Posts: 814
Default

Compared to his old benchmark of 54 seconds for the same task!
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 Off

Forum Jump

   

All times are GMT -4. The time now is 01:27 AM.


 

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