Hi develpr! Great set of questions. I shared this thread with Keen IO's developer group - https://groups.google.com/forum/#!topic/keen-io-devs/dbBL9NhlVXU - and asked if anyone has relevant experience.

dzello said:

Hi develpr! Great set of questions. I shared this thread with Keen IO's developer group - https://groups.google.com/forum/#!topic/keen-io-devs/dbBL9NhlVXU - and asked if anyone has relevant experience.

Thanks dzello, I appreciate the link!

develpr

Its a great question. There's a few options, including like you said using a local message queue - which is similar to what I do now. A somewhat more simplistic approach is writing an in memory queue and using the __destruct method to send the the events in a single batch. The destructor will be called on the end of the request, so when you use Keen's batch method, this will allow you to keep it to a single api call.

I have also written a php client for Segment.com using Guzzle 4 and carried over some of their ideas in the original php4 client to handle this same situation - by default, that client uses the destructor as mentioned above. The source of that may be useful to you: BatchRequestSubscriber.php

The Keen IO client is also based on Guzzle (version 3) and supports event listeners, though implemented a little bit differently. Should be possible to port this over as your own subscriber and register it with the Keen IO Client if you wanted.

As mentioned, we have a centralized API / Service that uses Redis pub/sub to process this stuff asynchronously - since in a few of our applications response time on initial page load was hugely important (landing pages).

The benefit to this extra abstraction is it allowed me to ensure all requests ran locally on our network and I used Redis pub/sub as a type write buffer, to send the requests async. This keeps us at 25-30ms response times (AWS internal network) on event tracking requests where we don't care about responses. We can also switch out providers, from Segment to Keen IO, or straight to a database if we needed. Unfortunately, that code is internal and proprietary though.

This might have been a lot to cover in a single wall of text - but I if you have questions, let me know.