phpkin favors delayed processing

[codefromthecrypt]

One of the surprising optimizations of this project is that it intentionally suggests delaying spans into zipkin by a magnitude of minutes and also via external setup. In practice users treat zipkin as a near-realtime tool for troubleshooting production. We've had complaints when spans are delayed seconds. Moreover, there's no file format defined for zipkin at the moment. This means that anyone trying to setup some extra infrastructure will be burdened with figuring this out before they even stat. Finally, there's a suggestion that writing to logs is somehow safer to production than writing to zipkin. Regardless of whether you write to logs or a network channel, what saves you is doing so asynchronously.

I'd highly suggest adding at least an http transport which buffers before writing to zipkin. This would result in an easier and less custom tracer which sends data to zipkin like everything else. If you want to keep the logger because you like that, that's perfectly fine, just make it clear that this is not compatible with any other tracer in the ecosystem (which means some place way down in the advanced section imho).

[whitemerry]

Thanks for taks, you have completly right. I look at it from my point of view (we are storing eveything in files, then upload to zipkin and other logging services by background tasks).

I've added SimpleHttpLogger and updated documentation in #4 - take a look and tell what do you think.
Now i'll suggest SimpleHttpLogger becouse this doesn't require any work from person who implement phpkin

[codefromthecrypt]

Thanks, I think this will make things more accessible. I do still have a question though.. in your rationale, it suggests the primary reason for suggesting File is to not block a production request on reporting to zipkin. Does this imply the file write is asynchronous? Or are you hinting at less likely to cause a large delay? If asynchronous, is there some way to do async http or a separate thread in php? If it is possible then a lot of the rationale goes away.. it then just becomes an option for those with log scraping sites.

[whitemerry]

Writing to file is not asynchronous, but, especially in all my cases, was way faster than making request to external service (not only zipkin). In every request to website user need to wait (website logic + writing/send logs - so i'm choosing strategy witch requires less time to process), here is more info about page load time.

Of course you can make this request async. but you need to have in mind that php does not support native async. This can be providen by external libs like CURL but it always depends on implementation and you need to add request by your own in your application.

Later is getting more interesting because you have to watch the request blocks. Especially since the data to Zipkin need to be sent after the communication with other api (you need to collect all the metrics)... but after communication with other api's most often the application could already be done becouse does not have to much logic (especially front-end apps).

[codefromthecrypt]

I think this explanation sounds good for the README. Basically.. SimpleHttpLogger - Allows you to try zipkin right away. (reporter is what we usually call this) However, it is blocking to zipkin which means it will delay the response back to the caller. FileLogger - Allows you to setup asynchronous reporting to zipkin. While this is a synchronous write to disk, in practice latency impact to callers is minimal. (Note the file format and perhaps an example cron) AsyncHttpLogger - TODO: Allows you to report spans to zipkin without additional services like cron, and also without adding latency to callers. However, this relies on the curl library being present. Sound fair?

…

On 7 May 2017 8:36 pm, "Piotr Bugaj" ***@***.***> wrote: Writing to file is not asynchronous, but, especially in all my cases, was way faster than making request to external service (not only zipkin). In every request to website user need to wait (website logic + writing/send logs - so i'm choosing strategy witch requires less time to process), here is more info about page load time <https://blog.kissmetrics.com/speed-is-a-killer/>. Of course you can make this request async. but you need to have in mind that php doesn't not support native async. This can be providen by external libs like CURL but it always depends on implementation and you need to add request by your own in your application. Later is getting more interesting because you have to watch the request blocks. Especially since the data to Zipkin need to be sent after the communication with other api (you need to collect all the metrics)... but after communication with other api's most often the application could already be done becouse does not have to much logic (especially front-end apps). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD61xeaTkiG_LU_jNaq_JUse78nRF2xks5r3brCgaJpZM4NTC95> .

[whitemerry]

@adriancole sure thing, todo's added and differences added here with link back to this ticket.