Non-Reproducible? I can still fix that

How many times have you heard that an application problem is not reproducible? Yea, I know, if you're a veteran like me, way too many times and sleepless nights I bet. But non-reproducible errors are common for developers. Its just impossible most times to have development setup exactly like production when the problem was happening. There are different loads between Dev and Prod, servers and environments are typically different between them, and especially database differences, and lack of good forensic information about the problem make it hard to exactly duplicate the situation that was happening to our customers on the website. So the problems fester, we learn to live with the kinks, even put ugly band-aid solutions because its all we could find. I recall talking to a developer once at Zendcon and he told me that they created a cron scrip that would restart the apache server every night to clear up a random problem that they kept having, that was the only fix he could find. And the amount of time and effort expended by developers and the staff to troubleshoot these issues start to take a toll on the project time lines. We did a survey here at Zend and interviewed 1500 developers and found that the majority spent over 30% or more of their time with maintenance and troubleshooting production issues. Non-reproducible problems don't have to be a drain on our resources anymore, we can still find them fast (and fix them) by using new diagnostics capabilities recently released in Zend Server 5.0

One of the most talked about capabilities in the latest release of Zend Server is Code Tracing that will help address problems like these in production. Code Tracing eliminates the difficult task of reproducing the problem by automatically capturing (in real-time) the full execution history of an application problem in production. If you can imaging Zend Server continually doing a historical debugger trace of your code in real time for each request, its like a flight recorder blackbox for your PHP application constantly monitoring and storing a trace only when a problem is discovered. But what's different between Zend Server 5.0 .vs. XDEBUG trace is that your performance is not penalized for this level of diagnostics. XDEBUG will write a trace to disk for each and every line it executes generating a very large trace file and incurring a significant performance hit. Zend Server 5.0 keeps trace information in memory as it executes PHP applications and if a problem is identified through the use of error thresholds, then it will save the information to disk for you to review the problem in more details. There is even a setting to keep the the Code Trace in sleep mode, and when an error event would trigger and wake up Code Tracing. This gives you both great performance in a production environment without sacrificing deep troubleshooting abilities with Code Tracing. If you havent had a chance to see how Code Trace can help cut your own troubleshooting times in half, take a look at this Code Trade webinar and be sure to download the GA version of Zend Server 5.0 today.