Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: vma on January 09, 2015, 08:50:13 AM
-
Hi guys,
So I was wondering what's your opinion here since I had a confrontation with a colleague :)
I say that it's not a problem to use ListGetDataCfg as many times as you want in a routing strategy since the transaction lists are loaded in memory when URS starts. My colleague says that optimal is to use ListGetDataCfg only once to read the entire list in a list type variable and then use GetStringKey when you need any key.
I know we are not doing real time programming here to be so concerned about memory used but it's still voice we're talking about so every ms counts.
So what do you say?
Regards,
Mihai
-
Would say how many calls? How much data on lists? Subkeys?
Storing them on the call can be a memory eater...but will be faster...but again....CAPS is a very important variable you must consider
-
Please correct someone if I am wrong, but doesn't ListGetDataCfg force URS to access config server? (I maybe wrong here). If so then obviously it adds a delay.
I usually pass everything into a variable in the beginning to:
1. have a clean strategy easy to understand
2. ease of debugging
3. prevent almost unlikely scenario of where data changes while in strategy execution
It sure seems as less CPU-intensive way of getting things done. Even if it does not access cfg/server for that.
-
Thanks for your replies.
I think that lists are loaded in memory when URS starts because you don't see access to config server every time you read data from list but it's the other way around, when ever you change something in config the URS gets a notification from config server. So since lists are in memory and the list variable used in the beginning of the strategy is also in memory I would say it's almost the same thing but you double the information in memory.
In my opinion the only benefit is, as victor is pointing out, that reading everything in the beginning is more for aesthetically purpose and of course you avoid changes of config while in strategy.
@cavagnaro I understand having higher CAPS uses more memory but we are talking theoretical here.
Regards,
Mihai
-
Except exrtreme cases of very big or very small lists it probably doesn't matter.
- URS reads all transactions lists on starting (and updates them later if needed by congig server notifications)
so it has all in memory.
- When ListGetDataCfg for some transaction list is used it gradually builds hash table
(by item name + property name) so next time if the same data will be asked it can be returned immeditelly
withoot any in memory search. Function just checks hash table and get data from there if found,
if not it will make linear search in entire transction list object and result will be added into hash table.
- When (if) transaction list is updated entire hash table for this transaction list object dropped and URS gradually
start to build it again.
- Just the same work when entire item is accessed - it stored in the same hash table. Following accessing separate
elements from this LIST variable which stores entire item however will means linear search in this list every
time some property is accessed.
-
Nice explanation terry :)
-
Due to numerous and major error within working with ListObject, I am strongly recommend to use database data "exchange" rather then ListObject, particulary in cases where these data are very important for folliowing routing or business deciding. The errors which I mean are, the URS is not notified about change on ListObjects and still working with "old" values or when the configuration server "lost" newly updated configuration during the switchover. Of course, these error is or should be resolved, but is up to you, if you want to risk business impact.
-
thank you terry, nicely put!
@Kubig database query may be safe but is very noneffective for time consuming.
Regards,
Mihai
-
Cannot agree, all depends on environment performance. If your database response are in seconds, there truly cannot be used SQL access from routing strategy. In general, standard response time for simple SQL command are approx in order of hundreds of miliseconds. But, it is just opinion based on real-life experience. On theory level, the access via ObjectList is the better way of course.