List:Eventum Development« Previous MessageNext Message »
From:Jeffrey D. Wheelhouse Date:March 11 2005 7:02am
Subject:Re: Why eventum may be slow...
View as plain text  
Hello,

Paul Mach wrote:
 > You're right, I'm an idiot. It doesn't have to run the code, it just
 > has to look for function headers. But 14000 lines for a simple issue
 > assign does seem like unneeded overhead.

I think you should really take a look at the PHP architecture before you 
go any further with claims of that nature.  A 14000 line (cached) 
sequential read is noise against the time of the first query.

I really shouldn't guess how much more likely those static PHP files are 
to get served from the buffer cache than any given DB block needed for a 
nontrivial issue list, but it's a lot.  Then there's lock contention 
over the hot DB blocks, IPC overhead, etc.  No comparison.

 > It is a laptop. But any modern operating system will cache frequently
 > accessed files in memory ( I have enought), so HD speed will not be
 > the problem. I would attribute it to bus or processor speed if
 > anything.

Unless the bus is already saturated from other sources or you are 
full-text searching a list with a few million issues, I can't fathom how 
bus contention or saturation could be an issue for a lightweight app 
like Eventum.  That is indeed less true on a laptop where all resources 
are continually squeezed, but you seem to agree running a production 
installation on a laptop verges on insanity.

Depending on your OS, all of your postulates should be trivially easy to 
test.  If your tests show anything significant about the resource 
utilization of Eventum, I for one would be very interested in that.  As 
far as I'm concerned, it can't go too fast.

 > I would never run a serious installation off a laptop either. But if
 > it is running slow with just little old me using it, what will happen
 > when there are lots of people on a legit machine?

I don't know what the largest usage load Eventum has had to date is, but 
when we go live with ours this weekend, I'll wager that we'll be making 
a pretty valiant run for the title.  I am feeling pretty good about that 
decision right now.*  If my opinion is different on Monday, you'll read 
all about it right here.

 > Also, I don't have
 > the resources to allocate a dedicated machine just for Eventum.

Nor do we.

I agree that Eventum is not without performance issues, but they are 
hardly show stoppers.  But more to the point, I agree fully with Joao's 
observation that any such problems are of a character and complexity 
unlikely to be unraveled by blind guesswork.

Thanks,
Jeff

*Joao and Bryan, I'll be feeling *really* good about it if you guys can 
possibly manage to squeak 1.5.1 out tomorrow and it has the email fixes 
previously discussed.

-- 
Jeff Wheelhouse
jdw@stripped
Thread
Why eventum may be slow...Paul Mach10 Mar
  • RE: Why eventum may be slow...Joao Prado Maia10 Mar
    • Re: Why eventum may be slow...Paul Mach11 Mar
      • Re: Why eventum may be slow...Jeffrey D. Wheelhouse11 Mar
        • RE: Why eventum may be slow...Joao Prado Maia11 Mar
          • Re: Why eventum may be slow...Jeffrey D. Wheelhouse11 Mar
      • RE: Why eventum may be slow...Joao Prado Maia11 Mar
        • Re: Why eventum may be slow...Jeffrey D. Wheelhouse11 Mar
          • RE: Why eventum may be slow...Joao Prado Maia11 Mar
            • Re: Why eventum may be slow...Jeffrey D. Wheelhouse11 Mar
              • RE: Why eventum may be slow...Joao Prado Maia11 Mar
  • Re: Why eventum may be slow...Phillip Steinbachs10 Mar