Re: 1.0.4 and 1.3.0 released

On Wed, 2002-05-22 at 18:28, Patrick Devine wrote:
> On 22 May 2002, Hunter Matthews wrote:
> 
> > Current may never scale to the extent that RHN does. They have half or a
> > dozen people working full time, and Really Big Hardware.
> 
> That's about right.. the team is about a dozen people (or was when I 
> left).  Most people work on the web management side of the app though 
> which is all written in perl.  There were only a couple guys doing the 
> python development.
> 
> With that said, the biggest bottleneck as far as I could tell seemed to be 
> the oracle database.

<shrug> I havne't looked at the sql stuff closely enough yet - I'm also
not a sql programmer. yet.

> 
> > However, if someone meant "Running Current locally for our x machines
> > works better than our x machines hitting RHN" then possibly.
> 
> I think if the app is designed correctly, we should be able to exceed 
> RHN's performance, especially with anonymous logins.  It should be 
> trivially easy to get multiple back-ends up and going to pump out packages 
> with some kind of load balancing or proxy cache.

according to some of the headers, I'm guessing thats how redhat does it.

IE, one or two machines doign all the python/db work, and many others
jamming rpms down the wire. 

I myself will be very happy when we simply have apache pushing the bulk
bits down the wire, instead of reading the whole rpm into ram with
python.

> 
> > The big advantage you'd likely see right now is that while each client
> > may in fact be a little slower (compression turned off), you'll be able
> > to scale to 20-40-?? simultaenous clients because apache can handle
> > simultaneous hits - Current 1.0 can't and won't.
> 
> I'm not sure the compression is really going to make that much of a 
> difference.  The RPM's themselves are already compressed so recompressing 
> them isn't going to buy anything.  I haven't looked enough through the 
> header data yet to see if compression would buy anything, but my 
> guess is that it would be minimal at best.  That's why benchmarks are so 
> handy though..

RHN doesn't compress the rpms, and shouldn't 
RHN doesn't compress the headers, and its a wash (some compress well,
but most are to small to matter to anyone but a modem user)

RHN does compress the packagelist, and its a HUGE win to do so, because
its big and XML, so it compresses VERY well.

-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.