fsockopen UDP connections should be non-blocking

[kiyanwang]

We are using fsockopen to create a stream so we can, connect and write to our StatsD server via UDP:

      if (!empty($this->host)) // if host is configured, send..
            {
                $fp = fsockopen("udp://{$this->host}", $this->port);
                if (! $fp) { return; }
                foreach ($sampledData as $stat => $value)
                {
                    if (is_array($value))
                    {
                        foreach ($value as $v)
                        {
                            fwrite($fp, "$stat:$v");
                        }
                    }
                    else
                    {
                        fwrite($fp, "$stat:$value");
                    }
                }
                fclose($fp);
            }
        }

From the PHP manual for fsockopen

The socket will by default be opened in blocking mode. You can switch it to non-blocking mode by using stream_set_blocking().

However, we are not telling PHP to make the stream non-blocking. As a consequence when this attempts to write to the StatsD server if the UDP buffer on the server is full, this call will block on the client and wait.

This P/R sets the stream to non blocking. This means that when it attempts to write, if the server is busy or the UDP buffer on the server is full this will no longer block and instead will return an error which we already ignore.

[camillef]

This is a good spot!

[rgubby]

Simple change but could make a massive difference to overall performance of any app using Tripod!

[kiyanwang]

I've deployed this fix to a tarl on demand staging environment and enabled sending stats to statsd on that box. I also had another ondemand instance that did not contain this fix. I created the same 224 item list (using a ris file) on both servers and proceeded load the list up in shipshape and monitor the response trace details in new relic.

The box with the fix was consistently faster than the box without. This isn't particularly empirical because there's no way these two boxes on their own would generate enough traffic to our statsd server to cause the udp buffer to fill up. What this did demonstrate is that there was no adverse affect after including this change,