Observation of app responsiveness

[TheDigitalOrchard]

By no means an authoritative conclusion, but when I switched to Amp\Log, I actually noticed more of a blocking behaviour than when using the standard Monolog StreamHandler. Not sure what the difference could be, or if Monolog is now non-blocking internally?

$handler = new Monolog\Handler\StreamHandler($this->file, Monolog\Logger::DEBUG);

// replaced with the followed introduced a noticeable delay

$handler = new Amp\Log\StreamHandler(Amp\File\openFile($this->file, 'w'), Monolog\Logger::DEBUG);

Just sharing in case anyone can see what I might be missing.

[Bilge]

Can you complete the script with an example of what you mean by more blocking?

[TheDigitalOrchard]

That one line of code is the only difference in a standard Monolog logging setup. When using Amp\Log\StreamHandler, rather than the page rendering instantly, there was a noticeable delay. Reverting back to Monolog\Handler\StreamHandler restored the instant rendering. That's the opposite of what I was expecting.

But in the end, I discovered that there must be more to how AMPHP works that I don't understand. Today, I spent quite a bit of time trying to figure out why none of my classes' __destruct() methods were being called. As soon as I removed all instances of Amp\Log from my code, they were called again.

So, clearly I need to learn more about how this library works before including it in my code.

[kelunik]

@TheDigitalOrchard There shouldn't be a difference whether __destruct() is called. Do you have an example where you can reproduce this behavior in a simpler setup?

[trowski]

@TheDigitalOrchard Something to note: Unless you are running multiple coroutines which are logging, you may actually notice a slowdown because asynchronous writes have more overhead than synchronous writes. The advantage is that you can be waiting on multiple asynchronous writes while performing other tasks, whereas you can only perform one synchronous write at a time and cannot do other work. Additionally, the default driver in amphp/file uses amphp/parallel, which is slower than using one of the extensions for async file writing, such as ext-eio or ext-uv.

The destructor behavior sounds very odd indeed. Amp does nothing to change the fundamentals of PHP behavior, so destructors should be called as normal. It sounds like something else may have changed. If a destructor is not called at the expected time, I'd wager a circular or static reference was created preventing automatic garbage collection.