4 ms·

Forking seems like a very expensive solution to the problem. Especially in php where exec() doesn't actually do what exec in unix does in general (contrary to p

by pilif 14y ago

Forking seems like a very expensive solution to the problem. Especially in php where exec() doesn't actually do what exec in unix does in general (contrary to plain exec which you'd use after a fork, PHP's exec still runs a shell). If you use their API even just one time per request, be aware that they will fork, execute a shell, fork again and then execute curl. Imagine where this is going when you use multiple API calls per request. As this is "just" about analytics, why not use a UDP packet or two? Sure - they might not get delivered, but is that really so bad for analytics? Sending out a UDP package is very fast and there will be no waiting going on at all.

tbh 14y ago
DNS resolution also blocks, and PHP doesn't appear to have a plugin for async DNS resolution.
- pilif 14y ago
  If you have a local DNS cache or at least a powerful DNS server close to you, this should really not be that much of a problem as the DNS server would be able to respond quickly from its local cache. I doubt you'd lose much more than 20ms. That's still way better than forking tons and tons of curl processes and shells.
calvinfo 14y ago
Author here. You're right that if you end up dealing with many requests per second, it will end up being resource intensive. In that case, the file or even a dedicated queue are better options. We actually queue calls to our API and send only a single request to our servers. Even if you make multiple API calls over the course of a request, there will still be one fork per request. I'd actually wanted to include UDP, PHP Extensions, and persistent sockets as part of the article, they just ended being a little out of scope. We might try and support them in the future, UDP is definitely an interesting idea for analytics applications. We may also end up writing a custom in-memory queue which uses a persistent socket. For a vanilla PHP install, these seemed like the best available options.
- mratzloff 14y ago
  Yes, UDP is a good solution for analytics. StatsD uses UDP.
- duggan 14y ago
  UDP is kinda the only game in town with in-app analytics (if you don't want to drop ZeroMQ all over the place); Metricfire's PHP (and other) client libraries have been on this for a while now - http://docs.metricfire.com/ http://docs.metricfire.com/

by pilif 14y ago

tbh 14y ago

DNS resolution also blocks, and PHP doesn't appear to have a plugin for async DNS resolution.

pilif 14y ago
If you have a local DNS cache or at least a powerful DNS server close to you, this should really not be that much of a problem as the DNS server would be able to respond quickly from its local cache. I doubt you'd lose much more than 20ms. That's still way better than forking tons and tons of curl processes and shells.

calvinfo 14y ago

Author here. You're right that if you end up dealing with many requests per second, it will end up being resource intensive. In that case, the file or even a dedicated queue are better options. We actually queue calls to our API and send only a single request to our servers. Even if you make multiple API calls over the course of a request, there will still be one fork per request. I'd actually wanted to include UDP, PHP Extensions, and persistent sockets as part of the article, they just ended being a little out of scope. We might try and support them in the future, UDP is definitely an interesting idea for analytics applications. We may also end up writing a custom in-memory queue which uses a persistent socket. For a vanilla PHP install, these seemed like the best available options.

mratzloff 14y ago
Yes, UDP is a good solution for analytics. StatsD uses UDP.
duggan 14y ago
UDP is kinda the only game in town with in-app analytics (if you don't want to drop ZeroMQ all over the place); Metricfire's PHP (and other) client libraries have been on this for a while now - http://docs.metricfire.com/ http://docs.metricfire.com/