On 28 Feb 2012, at 23:14, Daevid Vincent wrote:
> My question is, is there a way to enable some PHP configuration that would
> output more verbose information, such as a backtrace or the URL attempted?
>
> In our PHP error log, we have the usual semi-useful information. However
> this is only a partial story as it's hard to re-create the URL that caused
> the error. In the first Actor example, yeah actor_id 2206 doesn't exist and
> so now I have put a try/catch on all pages that have "new Actor($actor_id)"
> but it doesn't tell me WHY this is happening. How did someone get to this
> point? I doubt they just randomly picked '2206' which happens to be one of
> only a handful of actually missing actors out of 100k. Sure I guess it could
> be a bot that sequentially tried them all, but this is not likely since we
> have SEO style URLs and so we re-map an actor name back to the ID. So the
> bot would have to try NAMEs not IDs. This means we must have some link
> somewhere that points to this. Same with the common foreach() warnings
> below. Yeah, the array being passed is empty/null. Sure I can check the
> array before doing the foreach() or even @foreach() but that doesn't tell me
> the root cause. What video are they trying to access that has no scenes or
> invalid actors?
>
> We do NOT have apache logging turned on as we get 30,000 hits per second and
> it would be too expensive. I only care about PHP errors like this. And the
> apache error log (which we do have enabled) doesn't have useful info related
> to these kinds of issues as they're really not apache's problem. That log
> only deals with missing files/images/pages/etc.
>
> [28-Feb-2012 13:43:19 UTC] PHP Fatal error: Uncaught exception
> 'ObjectNotFound' with message 'There is no such object Actor [2206].' in
> /home/SHARED/classes/base.class.php:103
> Stack trace:
> #0 /home/SHARED/classes/actor.class.php(61): Base->load_from_sql()
> #1 /home/m.videosz.com/browse_scenes.php(89): Actor->__construct(2206)
> #2 {main}
> thrown in /home/SHARED/classes/base.class.php on line 103
>
> [28-Feb-2012 10:54:01 UTC] PHP Warning: Invalid argument supplied for
> foreach() in /home/m.dev.com/scene.php on line 138
>
> [28-Feb-2012 07:22:50 UTC] PHP Warning: Invalid argument supplied for
> foreach() in /home/SHARED/classes/scene.class.php on line 423
Seriously? Errors like this should not be getting anywhere near your production servers. This is especially true if you're really getting 30k hits/s.
For a commercial, zero-hassle solution I can't recommend http://newrelic.com/ highly enough. Simple installation followed by highly detailed reports with zero issues (so far). They do a free trial of all the pro features so you can see if it gets you what you need. And no, I don't work for them, I just think they've built a freakin' awesome product that's invaluable when diagnosing issues that only occur in production. I've never used it on a site with that level of traffic, and I'm sure it won't be a problem, but you may want to only deploy it to a fraction of your infrastructure.
If you want a homemade solution, the uncaught exceptions are easily dealt with... CATCH THEM, do something useful with them, and then die gracefully. Rocket science this ain't! See the set_exception_handler function for an easy way to set up a global function to catch uncaught exceptions if you don't have a limited number of entry points.
You can similarly catch the warnings using the set_error_handler function, tho be aware that this won't be triggered for fatal errors.
But seriously... a minimal level of structured testing would prevent issues like this being deployed to your production servers. Sure, instrument to help resolve these issues now, but if I were you I'd be putting a lot of effort into improving your development process. Contact me off-list if you'd like to talk about this in more detail.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
