Splunk Search

How to improve transactions performance?

grio
Engager

Hi,all

index=C (sourcetype=A earliest=-3d latest=-2d) OR earliest=-3d latest=now sourcetype=B |transaction keepevicted=true ID

   sourcetype=A                                   sourcetype=B

_time                  id  name           _time                id   mode

------------------------------           ----------------------------------
10-11-08 上午16:05:57  001  a            10-11-08 上午16:59:57  001  aaa
10-11-08 上午17:52:58  002  b            10-11-09 上午15:59:58  002  bbb
10-11-08 上午20:51:58  003  c            10-11-10 上午17:59:58  003  ccc
10-11-08 上午21:50:58  004  d            10-11-10 上午17:59:58  006  ddd
10-11-08 上午22:20:58  005  e

---------------------------------------------------------------------------
I want results...
_time                  id  name mode  sourcetype

10-11-08 上午16:05:57  001  a    aaa   A  B
10-11-08 上午17:52:58  002  b    bbb   A  B
10-11-08 上午20:51:58  003  c    ccc   A  B                       
10-11-08 上午21:50:58  004  d          A
10-11-08 上午22:20:58  005  e          A

Set sourceType=A and B can not change the time

Big slow because the data

How to improve performance and speed?

My English is not good, I try to descript my questions carefully. hope you can understand what I mean.

Thanks a lot..

Tags (1)
0 Karma
1 Solution

sideview
SplunkTrust
SplunkTrust

I do not think that you can set two different time ranges like that.

However as far as performance issues with transaction I dont think you need to use transaction and you can use stats instead. Performance should be a bit better.

index=C ( sourcetype=A OR sourcetype=B ) 
| eval is_too_recent_A=if(searchmatch("sourcetype=process_control"),if(_time>relative_time(now(), "@m"),1,0),0)
| search is_too_recent_A=0
| stats values(*) as * by ID

Note that I create a field called is_too_recent, and the value will be 1 only when both sourcetype=A and the _time value is within today. Then the search clause removes those events from the set. And then the stats clause essentially does what your transaction as doing. The main difference is that the raw event text will be gone and you'll have only fields.

And instead of stats values(*) as * by ID you may want to do something more specific like this:

stats sum(someNumericField) avg(someOtherNumericField) first(someTextField) as someTextField by ID

View solution in original post

sideview
SplunkTrust
SplunkTrust

I do not think that you can set two different time ranges like that.

However as far as performance issues with transaction I dont think you need to use transaction and you can use stats instead. Performance should be a bit better.

index=C ( sourcetype=A OR sourcetype=B ) 
| eval is_too_recent_A=if(searchmatch("sourcetype=process_control"),if(_time>relative_time(now(), "@m"),1,0),0)
| search is_too_recent_A=0
| stats values(*) as * by ID

Note that I create a field called is_too_recent, and the value will be 1 only when both sourcetype=A and the _time value is within today. Then the search clause removes those events from the set. And then the stats clause essentially does what your transaction as doing. The main difference is that the raw event text will be gone and you'll have only fields.

And instead of stats values(*) as * by ID you may want to do something more specific like this:

stats sum(someNumericField) avg(someOtherNumericField) first(someTextField) as someTextField by ID

grio
Engager

I updated the results,Look for your reference,Thanks a lot..

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

From Data to Insight: Announcing the Winners of the Splunk Dashboard Contest

Hi Splunkers, First off, thank you to everyone who participated in our very first From Data to Insight: The ...

Splunk Developers: Construct Your Future at the .conf26 Builder Bar

Calling all Splunk architects, platform admins, and app developers: the site is open, and the blueprints are ...

Quick connection discovery mode for forwarders

When a Splunk forwarder loses connectivity to its indexers, it does not always reconnect immediately. In many ...