Jira (FACT-2551) Resolver is called multiple times even if the fact cannot be resolved

0 views
Skip to first unread message

Gheorghe Popescu (Jira)

unread,
Apr 14, 2020, 5:24:04 AM4/14/20
to puppe...@googlegroups.com
Gheorghe Popescu created an issue
 
Facter / Improvement FACT-2551
Resolver is called multiple times even if the fact cannot be resolved
Issue Type: Improvement Improvement
Assignee: Unassigned
Created: 2020/04/14 2:23 AM
Priority: Normal Normal
Reporter: Gheorghe Popescu

This can have major performance implications if the resolver is slow.

 

Context:

Facter 4 is caching resolver data so that resolver that are used by multiple facts to make the system calls only once.

 

Issue:

If a fact cannot be retrieved from the system, the resolver is called each time that fact is request, and all the system calls are done again.

 

Example: 

OS X system_profiler : https://github.com/puppetlabs/facter-ng/blob/master/lib/resolvers/macosx/system_profiler_resolver.rb#L38 does not have information about `subsystem_vendor_id`

OS X is_virtual is calling again for the `subsystem_vendor_id`: https://github.com/puppetlabs/facter-ng/blob/975344c6a0bdde9bbc208ff6381c00733a48e0c0/lib/facts/macosx/is_virtual.rb#L25

 

This makes the resolver to make 2 expensive system calls of ~0.4 seconds each(2/3 of total facter run)

 

Backtrace:

❯ bx facter------------------------------------------First Call
fact_list: {}
fact_name: model_identifier
 
       user     system      total        real
   0.031205   0.021051   0.291823 (  0.438509)
--------------------------------------------------
calling retrieve_system_profiler
["facter-ng/lib/resolvers/macosx/system_profiler_resolver.rb:40:in `block in post_resolve'",
 "facter-ng/lib/resolvers/macosx/system_profiler_resolver.rb:40:in `fetch'",
 "facter-ng/lib/resolvers/macosx/system_profiler_resolver.rb:40:in `post_resolve'",
 "facter-ng/lib/resolvers/base_resolver.rb:21:in `block in resolve'",
 "facter-ng/lib/resolvers/base_resolver.rb:19:in `synchronize'",
 "facter-ng/lib/resolvers/base_resolver.rb:19:in `resolve'",
 "facter-ng/lib/facts/macosx/is_virtual.rb:19:in `hypervisor_name'",
 "facter-ng/lib/facts/macosx/is_virtual.rb:15:in `virtual?'",
 "facter-ng/lib/facts/macosx/is_virtual.rb:9:in `call_the_resolver'",
 "facter-ng/lib/framework/core/fact/internal/core_fact.rb:12:in `create'",
 "facter-ng/lib/framework/core/fact/internal/internal_fact_manager.rb:27:in `block (2 levels) in start_threads'"]
--------------------------------------------------
Second Call
 
fact_list: {
  :model_name=> 'value'
  :model_identifier=> 'value'
  :processor_name=> 'value'
  :processor_speed=> 'value'
  :number_of_processors=> 'value'
  :total_number_of_cores=> 'value'
  :l2_cache_per_core=> 'value'
  :l3_cache=> 'value'
  :"hyper-threading_technology"=> 'value'
  :memory=> 'value'
  :boot_rom_version=> 'value'
  :smc_version_system=> 'value'
  :serial_number_system=> 'value'
  :hardware_uuid=> 'value'
  :system_version=> 'value'
  :kernel_version=> 'value'
  :boot_volume=> 'value'
  :boot_mode=> 'value'
  :computer_name=> 'value'
  :user_name=> 'value'
  :secure_virtual_memory=> 'value'
  :system_integrity_protection=> 'value'
  :time_since_boot=> 'value'
}
fact_name: subsystem_vendor_id
 
 
       user     system      total        real
   0.000297   0.001640   0.209305 (  0.430579)
--------------------------------------------------
calling retrieve_system_profiler
["facter-ng/lib/resolvers/macosx/system_profiler_resolver.rb:40:in `block in post_resolve'",
 "facter-ng/lib/resolvers/macosx/system_profiler_resolver.rb:40:in `fetch'",
 "facter-ng/lib/resolvers/macosx/system_profiler_resolver.rb:40:in `post_resolve'",
 "facter-ng/lib/resolvers/base_resolver.rb:21:in `block in resolve'",
 "facter-ng/lib/resolvers/base_resolver.rb:19:in `synchronize'",
 "facter-ng/lib/resolvers/base_resolver.rb:19:in `resolve'",
 "facter-ng/lib/facts/macosx/is_virtual.rb:25:in `hypervisor_name'",
 "facter-ng/lib/facts/macosx/is_virtual.rb:15:in `virtual?'",
 "facter-ng/lib/facts/macosx/is_virtual.rb:9:in `call_the_resolver'",
 "facter-ng/lib/framework/core/fact/internal/core_fact.rb:12:in `create'",
 "facter-ng/lib/framework/core/fact/internal/internal_fact_manager.rb:27:in `block (2 levels) in start_threads'"]
--------------------------------------------------

 

 

 

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Gheorghe Popescu (Jira)

unread,
Apr 14, 2020, 5:25:02 AM4/14/20
to puppe...@googlegroups.com
Gheorghe Popescu updated an issue
Change By: Gheorghe Popescu
This can have major performance implications if the resolver is slow.

 

* Context: *

Facter 4 is caching resolver data so that resolver that are used by multiple facts to make the system calls only once.

 

* Issue: *

If a fact cannot be retrieved from the system, the resolver is called each time that fact is request, and all the system calls are done again.


 

* Example: *  


OS X system_profiler : [https://github.com/puppetlabs/facter-ng/blob/master/lib/resolvers/macosx/system_profiler_resolver.rb#L38] does not have information about `subsystem_vendor_id`

OS X is_virtual is calling again for the `subsystem_vendor_id`: [https://github.com/puppetlabs/facter-ng/blob/975344c6a0bdde9bbc208ff6381c00733a48e0c0/lib/facts/macosx/is_virtual.rb#L25]

 

This makes the resolver to make 2 expensive system calls of ~0.4 seconds each(2/3 of total facter run)

 

* Backtrace: *
{code:java}❯ bx facter------------------------------------------First Call
{code}
 

 

 

Gheorghe Popescu (Jira)

unread,
Apr 14, 2020, 5:26:04 AM4/14/20
to puppe...@googlegroups.com
Gheorghe Popescu updated an issue
This can have major performance implications if the resolver is slow.

*Context:*

Facter 4 is caching resolver data so that resolvers that are used by multiple facts make the system calls only once.

*Issue:*

If a fact cannot be retrieved from the system, the resolver is called each time that fact is
request requested , and all the system calls are done again. 

*Example:* 


OS X system_profiler : [https://github.com/puppetlabs/facter-ng/blob/master/lib/resolvers/macosx/system_profiler_resolver.rb#L38] does not have information about `subsystem_vendor_id`

OS X is_virtual is calling again for the `subsystem_vendor_id`: [https://github.com/puppetlabs/facter-ng/blob/975344c6a0bdde9bbc208ff6381c00733a48e0c0/lib/facts/macosx/is_virtual.rb#L25]

 

This makes the resolver to make 2 expensive system calls of ~0.4 seconds each(2/3 of total facter run)

*Backtrace:*

Gheorghe Popescu (Jira)

unread,
Apr 14, 2020, 5:26:04 AM4/14/20
to puppe...@googlegroups.com
Gheorghe Popescu updated an issue
This can have major performance implications if the resolver is slow.

*Context:*

Facter 4 is caching resolver data so that resolver resolvers that are used by multiple facts to make the system calls only once.

*Issue:*

If a fact cannot be retrieved from the system, the resolver is called each time that fact is request, and all the system calls are done again. 

Gheorghe Popescu (Jira)

unread,
Apr 14, 2020, 5:46:03 AM4/14/20
to puppe...@googlegroups.com
Gheorghe Popescu updated an issue
This can have major performance implications if the resolver is slow.

*Context:*

Facter 4 is caching resolver data so that resolvers that are used by multiple facts make the system calls only once.

*Issue:*

If a fact cannot be retrieved from the system, the resolver is called each time that fact is requested, and all the system calls are done again. 
*Proposed solution:*   system call could be memoized. 

 

Gheorghe Popescu (Jira)

unread,
Apr 29, 2020, 3:04:04 AM4/29/20
to puppe...@googlegroups.com

Mihai Buzgau (Jira)

unread,
Aug 11, 2020, 7:13:03 AM8/11/20
to puppe...@googlegroups.com
Mihai Buzgau commented on Improvement FACT-2551
 
Re: Resolver is called multiple times even if the fact cannot be resolved

Base resolver should set nil on facts that cannot be resolved.

Mihai Buzgau (Jira)

unread,
Aug 11, 2020, 8:24:05 AM8/11/20
to puppe...@googlegroups.com

Mihai Buzgau (Jira)

unread,
Aug 11, 2020, 8:29:03 AM8/11/20
to puppe...@googlegroups.com

Bogdan Irimie (Jira)

unread,
Aug 19, 2020, 10:19:04 AM8/19/20
to puppe...@googlegroups.com
Bogdan Irimie updated an issue
Change By: Bogdan Irimie
Sprint: ready for triage ghost-26.08

Bogdan Irimie (Jira)

unread,
Aug 19, 2020, 10:20:03 AM8/19/20
to puppe...@googlegroups.com

Bogdan Irimie (Jira)

unread,
Aug 26, 2020, 9:04:04 AM8/26/20
to puppe...@googlegroups.com
Bogdan Irimie updated an issue
Change By: Bogdan Irimie
Sprint: ghost-26.08 , ready for triage 2

Sebastian Miclea (Jira)

unread,
Sep 1, 2020, 4:59:02 AM9/1/20
to puppe...@googlegroups.com

Bogdan Irimie (Jira)

unread,
Sep 2, 2020, 9:07:05 AM9/2/20
to puppe...@googlegroups.com
Bogdan Irimie updated an issue
Change By: Bogdan Irimie
Sprint: ghost-26.08, ghost-2.09 , ready for triage 2
Reply all
Reply to author
Forward
0 new messages