Posted on 11-02-2016 02:54 PM
Wanted to ask...how many of you use "Like" as a variable?
Do you use it a lot? Do you use it a little? Do you consider using more surgical logic to avoid "Like"?
Do you know...or want to know...what potential impact there might be when using "Like" variable in Smart Computer Groups?
With Patch Management on the horizon, this is something worth discussing.
PS, see, I didn't once mention why it is a good/not good idea to use mds for EAs. :)
Don
Posted on 11-02-2016 02:56 PM
I use it 90% of the time TBH.
Posted on 11-02-2016 03:00 PM
What is the official jamf distinction between "like" and "is" ?
Posted on 11-02-2016 03:10 PM
Definitely use it pretty frequently myself...
Posted on 11-02-2016 03:10 PM
During some breakout sessions, at Jamf Nation User Conference 2016, we were told like
and not like
has more performance impact to your server than is
and/or is not
, because more calculation is required.
I would love to see something from Jamf on these criteria and performance.
We know how to use each, what we can use Jamf feedback on, is performance related.
This way the community can be aware, and keep it in mind when designing logic.
PS, see, for a second time, I did not mention using mds for EAs. I'm so proud of myself. :)
Don
Posted on 11-03-2016 03:09 AM
While there would be some performance differences, really it's NOT about that..
The difference between: ( is, is not ) and ( like, not like ) is often (though not exclusively) more to do with "Data Types".
is / is not: is obviously doing an equality match
while: like / not like: is obviously doing a fuzzy match (which is more computationally expensive)
Sometime there is no choice - if you want to get the criteria correct, sometimes you have to use the fuzzy 'like' match criteria. An Example would be Version Strings like: 16.0. ... ( 16.0, 16.0.0, 16.0.12 )
where it makes no sense to do 'an exact match'
Of course if you can do an exact match, then you can use: is / is not
So that's what it boils down to.. the 'Type of information involved' and whether or not you can use exact match criteria, or whether you need to use fuzzy match criteria.
Posted on 11-03-2016 06:12 AM
I'd like to see some more options like "Starts with". We use two character abbreviations for the school districts we work with and I'd imagine not having to search the whole string for something that is short and known to be at the beginning would save some resources.
Posted on 11-03-2016 07:25 PM
This is a good topic. Can it be looked at from the standpoint of pure mySQL? In other words, is the JSS (No I will not stop using that!) involved beyond creating the query from the criteria?
I would expect Jamf to have really good mySQL architects and DBAs, yet I am unaware of a white paper providing guidance on this. I've heard generalities like 'don't use more than 10 items of criteria' and 'multiple nested smart groups is bad'. But when we ask for better querying ability we get 'Not Planned' with NO explanation why not. :(
@donmontalvo Which breakout session were those discussions, and do you think it was caught on video?
Posted on 11-03-2016 08:34 PM
@cdenesha wrote:
I would expect Jamf to have really good mySQL architects and DBAs, yet I am unaware of a white paper providing guidance on this. I've heard generalities like 'don't use more than 10 items of criteria' and 'multiple nested smart groups is bad'.
DING DING DING! :)
We all like beer, right? We all want to have more than one beer, right? Well, unless you're hypoglycemic like me. :.(
If PersonA weighs N pounds and has X beers in Y minutes, it is reasonable to expect blood/alcohol level to get to Z. The only way to know if a threshold is met is to measure using a breathilizer.
If the breathilizer shows too high a value, you've exceeded the limit and you go to jail, lose your job, and end up in purgatory.
Because, as my esteemed colleague @SeanA would say, it's about metrics.
If JAMF provides a function, and we use it, and JSS slows down, and we are told we aren't doing anything wrong but the feature is like
or is not like
can cause performance issues, well, it's fair to ask.
Where are the metrics?
How many beers can we have before we can expect our performance to start to deteriorate? Beer is good, right? How many can we have before beer is not such a good thing?
Should we request a JSS breathilizer?
Jamf = bunch of really smart people. I think it's reasonable to expect some level of guidance in this topic. Please provide metrics, so we aren't flying blind.
Metrics will help us greatly. Even After Patch Managelent is ready for prime time. :) C'mon, one or two of @erin.miska's elves should be able to knock this out over a beer.
But just one beer. Because we don't want the quality of the article to deteriorate. Because. Metrics.
TIA,
Don
Posted on 08-09-2017 06:57 AM
Just a comment on the metrics: they should be exposed via the GUI (or the API but GUI is preferable, perhaps Settings -> JSS Information), and not something we would have to run against the DB itself. Because many of us are hosted with no DB access.
Posted on 10-20-2017 05:28 PM
@PeterClarke wrote:
Sometime there is no choice - if you want to get the criteria correct, sometimes you have to use the fuzzy 'like' match criteria. An Example would be Version Strings like: 16.0. ... ( 16.0, 16.0.0, 16.0.12 ) where it makes no sense to do 'an exact match'
There are choices, and it doesn't not make sense...just saying there are manageable, sustainable options such as leveraging major.minor
for these kinds of scenaros. :)
version
:
$ defaults read /Applications/Google Chrome.app/Contents/Info.plist CFBundleShortVersionString
61.0.3163.100
major.minor
version:
$ defaults read /Applications/Google Chrome.app/Contents/Info.plist CFBundleShortVersionString | cut -f1-2 -d"."
61.0
For reference.