[nycphp-talk] Advice on setting for testing server
Kristina D. H. Anderson
ka at kacomputerconsulting.com
Tue Aug 25 19:55:04 EDT 2009
Hi, sorry if this was covered anywhere previously in this thread, but
I've found it useful, in addition to enabling the full error reporting
that's built into PHP, to also add customized error_log calls anywhere
where you have such things as database inserts/updates, web service
request/response or other behind-the-scenes text generation or
processing, or any other areas of the application which you feel are
extremely performance intensive, bug-prone or hard to monitor using
more generic error messages.
Set it up so that you can toggle this function on/off in one place
before turnover to production, so that you can leave in all your calls
to error_log for future use.
Your error_log file on the server will quickly grow to enormous
proportions, but since it's only a test server, it won't be a worry!
By doing this you can build a history of the application's behavior and
performance and verify that everything is exactly as it should be.
Right now I'm working with the Paypal IPN code and I'm finding that
it's quite a creative experience to figure out what, in any particular
instance, is the highest level of valuable information you can wreak
out of some code by dint of the old error_log function...I'd love to
see some error handling examples from people on this list which are
undoubtedly leaps and bounds above what I've got going on here...!!
> Ajai Khattri wrote:
> >> Do any of you have recommendations on configuration settings to
> > Most of these packages come with pretty sensible config settings so
> > probably would *not* mess with them without knowing the
> Duly noted.
> >> Which packages/extensions/modules should be installed/enabled?
> > That kind of depends on what software you're writing dont you
> Ah, right--thinking. Sometimes I forget to do that. Yes, that would
> sensible thing to consider. :-)
> > frameworks will need additional extensions and tweaks to Apache so
> > is no simple fits-all rule. The other thing to consider is that any
> > changes you make should be easy to maintain and put back after a
> > update. (In the case of Apache I tend to leave the main config
> > any changes will likely be overwritten when the software is
> > Ubuntu has something like a sites-enabled/sites-available folder
> > can put vhost files (one per vhost is good practice). I usually
> > file called ALL that contains any global config tweaks.
> >> Should I go ahead and turn off error reporting and enable it via my
> >> scripts, or should I leave it on all the time? If I should leave
> >> at what level should I set it? E_ALL?
> > If you're using a framework it might already do all that for you
> > provide its own config file for you to tweak that in.
> I'll look into all that, thanks.
> > Firebug is good on the browser side (also look at the Web Developer
> > Toolbar and the YSlow extension for Firebug). On the server side
> > FirePHP and Xdebug extensions for PHP.
> Firebug, YSlow, and the Web Developer Toolbar have been my best
> for front-end work for quite some time. I've seen the FirePHP & Xdebug
> extensions but didn't really understand how to use them, so I just
> ignored them. Now that you've mentioned them I'll go back and give
> a closer look.
> > All developers should be using version control. Subversion is very
> > but Git is also becoming so these days.
> New York PHP User Group Community Talk Mailing List
More information about the talk