<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Is this performance acceptable? in Monitoring Splunk</title>
    <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302107#M2826</link>
    <description>&lt;P&gt;@echen6... indexes in Splunk in not same as indexes in SQL. Every type of data fed to Splunk is Indexed i.e. indexes in Splunk can be treated more like Databases where data is stored (actually there is whole lot to how indexing works (&lt;A href="http://docs.splunk.com/Documentation/Splunk/latest/Indexer/HowSplunkstoresindexes"&gt;http://docs.splunk.com/Documentation/Splunk/latest/Indexer/HowSplunkstoresindexes&lt;/A&gt;).&lt;/P&gt;

&lt;P&gt;Since Splunk stores time series data from any kind of structured or unstructured data, sourcetype is something you use to define what kind of data you are ingesting. So sourcetype you can compare to tables in the database. Again it is not that simple ( it provides Schema-on-the-fly with search time field discovery). Smart Mode and Verbose Modes enable the same in Search Time. By default it is based on each Key Value pair or any field extractions/transformations you have defined. It can be changed to json, xml or can be turned off based on your data. Please go through the Splunk Tutorial course on Splunk Education for a quick start with Splunk:&lt;BR /&gt;
&lt;A href="http://www.splunk.com/view/SP-CAAAH9U"&gt;http://www.splunk.com/view/SP-CAAAH9U&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;Also for transitioning from SQL to Splunk Processing Language (SPL) you can refer to the following:&lt;A href="https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/SQLtoSplunk"&gt;https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/SQLtoSplunk&lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Fri, 19 May 2017 05:07:12 GMT</pubDate>
    <dc:creator>niketn</dc:creator>
    <dc:date>2017-05-19T05:07:12Z</dc:date>
    <item>
      <title>Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302101#M2820</link>
      <description>&lt;P&gt;We doing a search on index again a one field&lt;/P&gt;

&lt;P&gt;index=cog-nativedatastore-nonprod AND source="/logs/uamdsgl/nds-app-subscription-service/splunk-integrator/&lt;EM&gt;splunk-application.&lt;/EM&gt;" |  search tracking.system=itrac&lt;/P&gt;

&lt;P&gt;When inspecting the job&lt;/P&gt;

&lt;P&gt;This search has completed and has returned &lt;STRONG&gt;4,025&lt;/STRONG&gt; results by scanning &lt;STRONG&gt;106,856&lt;/STRONG&gt; events in &lt;STRONG&gt;9.964&lt;/STRONG&gt; seconds.&lt;/P&gt;

&lt;P&gt;I believe this is slow. The internal Splunk SME mentioned that the field I searched on is already indexed based on the screenshot below. Is there any other way to improve the performance on this search?&lt;/P&gt;

&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper" image-alt="alt text"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/2965i1682B6C292D79A36/image-size/large?v=v2&amp;amp;px=999" role="button" title="alt text" alt="alt text" /&gt;&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 18 May 2017 04:36:56 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302101#M2820</guid>
      <dc:creator>echen6</dc:creator>
      <dc:date>2017-05-18T04:36:56Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302102#M2821</link>
      <description>&lt;P&gt;Have you tried it this way?&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;index=cog-nativedatastore-nonprod AND source="/logs/uamdsgl/nds-app-subscription-service/splunk-integrator/splunk-application." tracking.system="itrac"
&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Thu, 18 May 2017 19:25:27 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302102#M2821</guid>
      <dc:creator>DalJeanis</dc:creator>
      <dc:date>2017-05-18T19:25:27Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302103#M2822</link>
      <description>&lt;P&gt;I second @DalJeanis's suggestion... including as much filters in base search is better than filtering the results afterwards. Your search will fetch 100K results from index and then filter only 4K results. While DalJeanis's search will fetch only 4K events to start with.&lt;/P&gt;

&lt;P&gt;Try to include &lt;STRONG&gt;sourcetype&lt;/STRONG&gt; also in your base search. While pulling the results splunk will know data type.&lt;/P&gt;

&lt;P&gt;Finally since you are seeing all the interesting fields, it implies you are running search in Verbose mode. Once you have identified/analyzed your interesting fields, you should run the searches in &lt;STRONG&gt;Fast Mode&lt;/STRONG&gt;.&lt;/P&gt;

&lt;P&gt;Refer to following docs:&lt;/P&gt;

&lt;P&gt;&lt;A href="https://docs.splunk.com/Documentation/Splunk/latest/Search/Quicktipsforoptimization"&gt;https://docs.splunk.com/Documentation/Splunk/latest/Search/Quicktipsforoptimization&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;&lt;A href="http://docs.splunk.com/Documentation/Splunk/latest/Search/Writebettersearches"&gt;http://docs.splunk.com/Documentation/Splunk/latest/Search/Writebettersearches&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;If these do not resolve performance do let us know more details as it might be due graver infrastructure issues like index bucket size.&lt;/P&gt;</description>
      <pubDate>Thu, 18 May 2017 19:52:58 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302103#M2822</guid>
      <dc:creator>niketn</dc:creator>
      <dc:date>2017-05-18T19:52:58Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302104#M2823</link>
      <description>&lt;P&gt;plus 1 for &lt;CODE&gt;Fast Mode&lt;/CODE&gt; . If you include all fields you are interested in the base search like this &lt;CODE&gt;field=*&lt;/CODE&gt; splunk will extracted for you even in &lt;CODE&gt;Fast Mode&lt;/CODE&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 18 May 2017 22:33:18 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302104#M2823</guid>
      <dc:creator>MuS</dc:creator>
      <dc:date>2017-05-18T22:33:18Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302105#M2824</link>
      <description>&lt;P&gt;Thanks @DalJeanis. Now the search time is 1/3 of what it was before after I put the filter in base search.&lt;/P&gt;

&lt;P&gt;@niketnilay, it didn't gain much on adding sourceType as I only have one sourceType in this index. &lt;/P&gt;

&lt;P&gt;And switching to fast mode brought 25% performance gain in this case!&lt;/P&gt;</description>
      <pubDate>Thu, 18 May 2017 23:40:52 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302105#M2824</guid>
      <dc:creator>echen6</dc:creator>
      <dc:date>2017-05-18T23:40:52Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302106#M2825</link>
      <description>&lt;P&gt;@DalJeanis @niketnilay. Are those interesting fields actual (SQL like) indexes in Splunk? Can we specifically add  "indexes" on fields?&lt;/P&gt;</description>
      <pubDate>Thu, 18 May 2017 23:53:52 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302106#M2825</guid>
      <dc:creator>echen6</dc:creator>
      <dc:date>2017-05-18T23:53:52Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302107#M2826</link>
      <description>&lt;P&gt;@echen6... indexes in Splunk in not same as indexes in SQL. Every type of data fed to Splunk is Indexed i.e. indexes in Splunk can be treated more like Databases where data is stored (actually there is whole lot to how indexing works (&lt;A href="http://docs.splunk.com/Documentation/Splunk/latest/Indexer/HowSplunkstoresindexes"&gt;http://docs.splunk.com/Documentation/Splunk/latest/Indexer/HowSplunkstoresindexes&lt;/A&gt;).&lt;/P&gt;

&lt;P&gt;Since Splunk stores time series data from any kind of structured or unstructured data, sourcetype is something you use to define what kind of data you are ingesting. So sourcetype you can compare to tables in the database. Again it is not that simple ( it provides Schema-on-the-fly with search time field discovery). Smart Mode and Verbose Modes enable the same in Search Time. By default it is based on each Key Value pair or any field extractions/transformations you have defined. It can be changed to json, xml or can be turned off based on your data. Please go through the Splunk Tutorial course on Splunk Education for a quick start with Splunk:&lt;BR /&gt;
&lt;A href="http://www.splunk.com/view/SP-CAAAH9U"&gt;http://www.splunk.com/view/SP-CAAAH9U&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;Also for transitioning from SQL to Splunk Processing Language (SPL) you can refer to the following:&lt;A href="https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/SQLtoSplunk"&gt;https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/SQLtoSplunk&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 19 May 2017 05:07:12 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302107#M2826</guid>
      <dc:creator>niketn</dc:creator>
      <dc:date>2017-05-19T05:07:12Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302108#M2827</link>
      <description>&lt;P&gt;I just want to caveat what &lt;a href="https://community.splunk.com/t5/user/viewprofilepage/user-id/201110"&gt;@niketn&lt;/a&gt; said about "Every type of data fed to Splunk is Indexed".  That's not literally true in the way you might think.  Every word is indexed, but not every field is indexed. You can have index-time extracted fields, which ARE indexed, and search-time extracted fields, which are NOT.&lt;/P&gt;

&lt;P&gt;So, for example, if you are looking for all records where pet_type is "dog", and pet_type is a search-time field, then the system will have to scan all the records with the word "dog" in them - including the records for old TV shows about "Dog the Bounty Hunter", movie reviews about Benji and Cujo and Lady &amp;amp; the Tramp, and references to Congressional testimony by lawyer Lloyd Doggett to see if the value "dog" is in the pet_type field.&lt;/P&gt;

&lt;P&gt;The only way to add indexes on search-time extracted fields is to change them to index-time extraction... which should be done with caution, because it is not retroactive, and slows down indexing.  &lt;/P&gt;</description>
      <pubDate>Tue, 29 Sep 2020 14:07:31 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302108#M2827</guid>
      <dc:creator>DalJeanis</dc:creator>
      <dc:date>2020-09-29T14:07:31Z</dc:date>
    </item>
    <item>
      <title>Re: Is this performance acceptable?</title>
      <link>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302109#M2828</link>
      <description>&lt;P&gt;Nice.  The performance gain from fast mode is usually going to be even better than that, but in this unique case, where your filters had all been moved to the base search and there wasn't a lot of calculation being done on  the records before they were rejected, the savings was less than usual.&lt;/P&gt;</description>
      <pubDate>Fri, 19 May 2017 12:09:08 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Monitoring-Splunk/Is-this-performance-acceptable/m-p/302109#M2828</guid>
      <dc:creator>DalJeanis</dc:creator>
      <dc:date>2017-05-19T12:09:08Z</dc:date>
    </item>
  </channel>
</rss>

