<?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: Why does the receivers/simple REST endpoint massively slow down for events larger than 1kB? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Why-does-the-receivers-simple-REST-endpoint-massively-slow-down/m-p/51162#M9814</link>
    <description>&lt;P&gt;After a bit more debugging I've found the answer myself.&lt;/P&gt;

&lt;P&gt;The 1024 byte limit is actually in cURL, not Splunk.  (grep for TINY_INITIAL_POST_SIZE in the cURL source code if you want to see it.)&lt;/P&gt;

&lt;P&gt;When cURL is told to send a body bigger than 1kB, it adds the extra header "Expect: 100-continue" unless it's been specifically told otherwise.  So the workaround to the problem is to specify the header "Expect:" to cURL, which can be done on the command line by adding the -H 'Expect:' option.  Appending this to the curl command line in the script in the original question makes all 9 calls very fast, and this is fine as a workaround.&lt;/P&gt;

&lt;P&gt;However, this still implies that there's a 2 second delay inside splunkd when a POST is received containing the header "Expect: 100-continue".  It would be nice if splunkd didn't sleep so long in this situation.  There's more discussion of the same problem in a completely different application at &lt;A href="http://www.songkick.com/devblog/2012/11/27/a-second-here-a-second-there/"&gt;http://www.songkick.com/devblog/2012/11/27/a-second-here-a-second-there/&lt;/A&gt;.&lt;/P&gt;</description>
    <pubDate>Tue, 05 Mar 2013 12:14:48 GMT</pubDate>
    <dc:creator>dmr195</dc:creator>
    <dc:date>2013-03-05T12:14:48Z</dc:date>
    <item>
      <title>Why does the receivers/simple REST endpoint massively slow down for events larger than 1kB?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Why-does-the-receivers-simple-REST-endpoint-massively-slow-down/m-p/51161#M9813</link>
      <description>&lt;P&gt;I have been using the &lt;A href="http://docs.splunk.com/Documentation/Splunk/latest/RESTAPI/RESTinput#receivers.2Fsimple"&gt;receivers/simple&lt;/A&gt; endpoint to add events into Splunk, and have run into a major performance degradation that occurs when the size of the raw event text goes above 1kB.&lt;/P&gt;

&lt;P&gt;If I submit an event to receivers/simple where the raw event text is exactly 1024 bytes, I get a success response within a fraction of a second.  However, if I submit an event where the raw event text is 1025 bytes, it takes slightly over 2 seconds.&lt;/P&gt;

&lt;P&gt;The following script can be used to reproduce the problem:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;#!/bin/bash

A975=`head -c 975 &amp;lt; /dev/zero | tr '\0' a`
JUNK=$A975
    
for COUNT in {1..9}
do
   echo $COUNT
   time curl -k -u admin:changme 'https://localhost:8089/services/receivers/simple?source=receiver%20test&amp;amp;sourcetype=test&amp;amp;host=davids%2Dmacbook%2Dpro&amp;amp;index=main' -d "2013-03-05T10:00:0$COUNT This is summary event $COUNT $JUNK"
   JUNK=a$JUNK
done&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;The relevant bits of the output are:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;6
&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;
&amp;lt;response&amp;gt;
        &amp;lt;results&amp;gt;
                &amp;lt;result&amp;gt;  
                        &amp;lt;field k='_index'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;main&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='bytes'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;1024&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='host'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;davids-macbook-pro&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='source'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;receiver test&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='sourcetype'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;test&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                &amp;lt;/result&amp;gt;
        &amp;lt;/results&amp;gt;
&amp;lt;/response&amp;gt;
        
real    0m0.019s
user    0m0.005s
sys     0m0.005s
7
&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;
&amp;lt;response&amp;gt;        
        &amp;lt;results&amp;gt;
                &amp;lt;result&amp;gt;  
                        &amp;lt;field k='_index'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;main&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='bytes'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;1025&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='host'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;davids-macbook-pro&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='source'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;receiver test&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                        &amp;lt;field k='sourcetype'&amp;gt;
                                &amp;lt;value&amp;gt;&amp;lt;text&amp;gt;test&amp;lt;/text&amp;gt;&amp;lt;/value&amp;gt;
                        &amp;lt;/field&amp;gt;
                &amp;lt;/result&amp;gt;
        &amp;lt;/results&amp;gt;
&amp;lt;/response&amp;gt;

real    0m2.021s
user    0m0.005s
sys     0m0.005s&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;If you run the whole script you'll see the timings are similarly fast for all raw event lengths up to 1024 bytes and similarly 2 seconds slower for all raw event lengths that are 1025 bytes and longer.&lt;/P&gt;

&lt;P&gt;Although the output above came from a Mac laptop running Splunk 4.3.2, I also get exactly the same problem on a Linux server running Splunk 5.0.1, so the problem seems to affect multiple platforms and versions.&lt;/P&gt;

&lt;P&gt;Does anyone know why this slowdown is happening?  Am I running into a limit that can be changed in a Splunk config file?  I've tried grepping for "1024" and "1kb" in all the .conf files and haven't found anything that looks likely, so any expert guidance would be much appreciated.&lt;/P&gt;</description>
      <pubDate>Tue, 05 Mar 2013 11:05:48 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Why-does-the-receivers-simple-REST-endpoint-massively-slow-down/m-p/51161#M9813</guid>
      <dc:creator>dmr195</dc:creator>
      <dc:date>2013-03-05T11:05:48Z</dc:date>
    </item>
    <item>
      <title>Re: Why does the receivers/simple REST endpoint massively slow down for events larger than 1kB?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Why-does-the-receivers-simple-REST-endpoint-massively-slow-down/m-p/51162#M9814</link>
      <description>&lt;P&gt;After a bit more debugging I've found the answer myself.&lt;/P&gt;

&lt;P&gt;The 1024 byte limit is actually in cURL, not Splunk.  (grep for TINY_INITIAL_POST_SIZE in the cURL source code if you want to see it.)&lt;/P&gt;

&lt;P&gt;When cURL is told to send a body bigger than 1kB, it adds the extra header "Expect: 100-continue" unless it's been specifically told otherwise.  So the workaround to the problem is to specify the header "Expect:" to cURL, which can be done on the command line by adding the -H 'Expect:' option.  Appending this to the curl command line in the script in the original question makes all 9 calls very fast, and this is fine as a workaround.&lt;/P&gt;

&lt;P&gt;However, this still implies that there's a 2 second delay inside splunkd when a POST is received containing the header "Expect: 100-continue".  It would be nice if splunkd didn't sleep so long in this situation.  There's more discussion of the same problem in a completely different application at &lt;A href="http://www.songkick.com/devblog/2012/11/27/a-second-here-a-second-there/"&gt;http://www.songkick.com/devblog/2012/11/27/a-second-here-a-second-there/&lt;/A&gt;.&lt;/P&gt;</description>
      <pubDate>Tue, 05 Mar 2013 12:14:48 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Why-does-the-receivers-simple-REST-endpoint-massively-slow-down/m-p/51162#M9814</guid>
      <dc:creator>dmr195</dc:creator>
      <dc:date>2013-03-05T12:14:48Z</dc:date>
    </item>
  </channel>
</rss>

