Re: Debugging

[Aaron Turner <aturner@linuxkb.org>]

First, the reduced font size on the sidebar is very good.  I like.

Reading this email, has me uh, concerned.  My reading, of this is that
this failed because there were slightly over 200 entries in the DB of type
"user".  And anytime we reach this magic number, we're going to have this
timeout problem.  One thing, why can't we increase the timeout?  There's
gotta be a setting.  

Why do you think this is a PHP timeout issue?  What is the limit in terms
of time?  Would getting a faster DB system help?  A faster web server? I
don't think re-writing this in C/C++ is something that will ever happen.
C/C++ is just too low level for this sort of thing.  And from the sounds
of it, I have this bad feeling that Zend won't be ready in time for us
either.  Which means examining other options; sooner rather than later.

Anyways, be sure to close the BugTraq tickets for this and any other
things you fixed. 

Anyways, I haven't had any time over the past week to work on the
CmdSchedule... things at work have been pretty insane.  I think my average
day at the office is something like 15 hours.  Anyways, tomorrow I hope to
put in a little time, but Monday I'll work as long as my battery holds out
on the plane to N.H.

On Sat, 4 Mar 2000, Jason Pincin wrote:

> OK.  I fixed the problem.  I moved dev over to yukon after commenting out
> the doc count code as well...
> 
> Kinda a serious problem actually, which I'm sure we'll come across again.
> When you load an object, the processing takes longer and longer as you
> get more and more children of that object.  Well, there were enough users
> signed up that php started timing out building all the child objects.
> 
> What I did to stave off the problem for now was add a parameter for
> render.php3 called &getchildren.  0 for false, 1 for true.  And I pointed
> the signup link to pass 0 into it so it doesn't load the children...
> since it doesn't need to anyway.
> 
> But, we'll eventually have this problem elsewhere in the tree as more and
> more content gets added.  We only have so much time before I need to
> start thinking of ways to optimize that section of code... or convert to
> PHP4.  But I think PHP4 will buy us more time only... eventually I'm
> going to simply impliment a more robust way of object retreival... 
> 
> it'd be nice if PHP4 bought us enough time for the C++ Daemon re-write.
> Not sure on that.
> 
> Anyway... it's functional again... 
> 
> 
> On Sat, Mar 04, 2000 at 06:23:18PM -0500, Jason Pincin wrote:
> > Do NOT migrate vodka's site to Yukon's.  There will be much debug code in
> > vodka til further notice.
> > 
> > -- 
> > Jason Pincin
> > Linux Knowledge Base Project Leader (http://www.linuxkb.org/)
> > http://vodka.linuxkb.org/~chardros/
> 
> -- 
> Jason Pincin
> Linux Knowledge Base Project Leader (http://www.linuxkb.org/)
> http://vodka.linuxkb.org/~chardros/
> 

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://www.linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
The difference between `Unstable' and `Usable' is only two characters: NT