The PHP community is large and diverse in their approach to build and run PHP applications. We have seen hundreds of small applications running on a handful of servers and one product running on multiple clusters and hundreds of servers across the globe. Still, we believe all PHP applications regardless of size benefit from monitoring, profiling and exception tracking functionality.
Last year we asked all our customers what they think we should work on and "Triggering Traces" came out on top. We started planning a prototype in Winter last year and are ready to share the current state and a few ideas ideas as we launch the beta program. The general release date is planned for late February/March.
We are happy to announce that our latest version of the Tideways extension (v5.0.22) includes support for the Spryker E-Commerce Platform through fully automated instrumentation and hooks into the core of Spryker. With the complexity of a large E-Commerce project, different channels, multiple language stores and landingpages for campaigns it is especially difficult to get a full view of the performance and errors from within your software as a project manager, developer or system administrator.
With all the customers running Tideways on their Magento, Oxid or Shopware shops I was interested in how in the aggregated average, those shops usually perform on Black Friday compared to the 8 weeks before and the weeks after leading up to Christmas. A lot of e-commerce shops have either large Black Friday, Cyber Monday or week long christmas campaigns, which can increase the traffic to the shops significantly.
A few weeks into year five of the Tideways project we are happy to announce the release of Tideways version 5, including large updates to all parts of the stack from PHP extension, daemon and the user-interface. Ladies and gentlemen, this is Tideways no. 5!
Having detailed response time percentiles and impact analysis for transactions is great. But often it's not the php application that is causing unwanted spikes in response times rather than services used by your application, such as MySQL, redis, HTTP APIs and so on.
Did you ever have a memory leak in your PHP program and couldn't locate the exact source in your code? From my experience with memory profiling in PHP, this is caused by the PHP engine and how it manages memory. PHP uses a custom memory manager on top of the native memory management in C for multiple reasons...
Memory profiling in PHP has traditionally been hard. Most memory profilers compare the memory or peak memory before and after a function call to find out how much memory usage increased or decreased. This can be achieved by calling the equivalent of memory_get_usage() and memory_get_peak_usage() functions from within the profiling extension.
We have just rolled out an improvement to the Time Explorer, the low precision (15 minutes) chart that is rendered in the Dashboard and Application view with performance data for the complete retention period of your plan. It is now shown directly below the the head navigation now and stays there when navigating through to snapshots or transaction details screen. Additionally it now includes the service and environment switchers that have been part of the main application graph before.
We have just pushed the beta of a new version 5.0 of our XHProf fork to Github. It is rewritten from scatch with a modern code-base that makes use of PHP 7 internals and includes major datastructure improvements.
