Re: Debugging

[Aaron Turner <aturner@linuxkb.org>]

On Mon, 6 Mar 2000, Jason Pincin wrote:

> > No, I got the "200 children of any kind".  That's what has me so
> > concerned.  What is the current time out?
> 
> How long did it take for thew error to come back on sign-up?  Thats what the timeout it.  You
> can find out by looking at php.ini.

10-15 secs or so if memory serves. 
 
> > Well, let me put it this way.  We have faster CPU's than what my company
> > uses for MUCH larger datasets.  I'm talking MILLIONS of records searched
> > per-query.  Our query time is < 2 seconds.  Yes, we use Oracle, but I'd
> > have a hard time believing that MySQL can't beat Oracle when you're
> > comparing < 500 records to > 6 million.
> 
> All the scalability in the world won't help you if you have
> non-optimized querys.  The query being generated on sign-up when the
> problem existed had over 200 "OR" statements... I'm not sure how that
> would be handled... probably poorly.

Ah... yes that would suck.  Not being an expert I have to think that
re-examining the DB layout would provide a bigger performance boost.
Maybe put each object type in it's own table?  I dunno, you're the expert.
More RAM to cache the entire DB wouldn't hurt either.  So basically the
problem isn't PHP, it's the SQL query sucked and PHP timed out waiting for
it to return.  Good to know.

> > Ok, let me re-phrase that.  Rewriting this in C/C++ won't happen in time
> > to help us.  Even if you stoped all PHP devel, and started on the C++
> > port, you're at least 18, probably closer to 36, months away to having
> > anything useful.  Not to mention everything that we have coded would be
> > thrown away.
> 
> Same prob with using perl.  We'd be throwing away a lot of existing stuff.

Not to get into a C vs Perl vs Python vs Whatever, but there is a huge
difference between C and all the others: what is commonly called "time to
market".  Writing in Perl or Python would be much quicker.  
 
> I'm not even considering a re-write at this point.

Fair enough.  Not suggesting we should.  I really hope we don't need one-
ever.

> > 1) Don't bet the farm on vapor-ware.  I know Zend is hardly vaporware, but
> > we don't have the ability to test it right now, and no idea when critical
> > bugs will be fixed.
> 
> I'm not betting the farm on it... I'm betting the farm on the fact
> that I can optimize the code enough to get us to the point where Zend
> is usable for us.

I guess I don't know where you're drawing the line.  No matter.
 
> > 3) You don't sound very confident that Zend will scale to meet our needs
> > in the forseeable future.
> 
> Yes I am.  For the forseeable future... Zend will kill mod_perl.

Hope you're right.  Honestly though, I'm less concerned about the
technology and more about the ability to get developers to help out.  

> > 4) Other options?  My gut says, Perl as it performs well (especially with
> > DB's) and is high-level enough where it won't take 3 years to develop a
> > usable site.  mod_perl is known to scale very well; slashdot, internet
> > movie database, Wired, and CBS MarketWatch all run mod_perl.  You might
> > want to check out Mason.  http://www.masonhq.com/  From what I understand,
> > kinda a Zope meets mod_perl.
> 
> A couple of things.  If I would re-write in something else, it
> wouldn't be perl.  It would be Python or C/C++.  C++ or Python are
> MUCH more object oriented than Perl.  Plus, I know them. And Python is
> just as high-level as Perl, and has proven scalability... All of Zope
> is written in Python... just about.

C++ really isn't much more OO than Perl.  Nothing in C++ requires you to
code in an OO manner, since the OO is just an addon.  One issue that I
think you're missing is the availablility of developers.  There are
probably more Perl coders who do OSS than C++ and Python combined.   I
don't know Python.  Does Daniel?  What about C++?  I don't.  Daniel?  And
franky, I doubt that you're doing anything OO-wise that isn't supported in
Perl.

And franky, I'm not sure OO is this silver bullet you make it out to be.
OO programs are slower and OO adds additional complexity and overhead.

My point isn't that we should choose Perl over Python or C++, or OO vs
non-OO.  My point is that you need to get developer buy-in on whatever
language we use.  If you want to get out of coding and start looking at
more big picture things, then this should be very important to you.  I
can't stress this enough. If you want to code forever, then do what you
will.  If you want to get out of coding like you always tell me you do,
then let the developers decide what to do.
 
> Anyway - my point is that any re-write would kill us.  I don't think
> the problem is big enough to warrant a re-write.  I think the problem
> is in how I wrote the functions, and I'll be examining ti closer
> today.  It's not like I have to trouble shoot everything... the
> object-init stuff, which is where the problem lies, is only 100 or 200
> lines of code.  I'm sure I can optimize it more.

I can't agree more.  We don't want to cross this bridge right now. 

-Aaron