[IRCServices] cheers. ideas.

[&quot]

Services is a READ ONCE, WRITE MANY application. If you make changes to the
data in the underlying datastore, be it a database, binary file or text
file, the changes would be lost at the next database save.

Services would require a lot of work to make it support proper querying of a
database. The performance hit services would take would outweigh the benefit
imho. If one were to do it properly, with multiple threads loading only the
information needed to service the users and channels currently online,
things would definately be better. However, let's be honest, this requires a
lot of developement, skills and time.

What we should focus on is writing an interface for Services that allows
external apps to communicate with it.

Back to your point about Brasnet, 98MB is a lot. However, it's not totally
unreasonable. The thing I'd guess that is really taking a hit is the CPU.
The algorithms were never meant to handle so much data. I am definately
looking to improve the key ones.

Andrew

----- Original Message -----
From: "Bruno Lacerda" <sniffer at sniffer.net>
To: <ircservices at Snow.shadowfire.org>
Sent: Wednesday, October 11, 2000 6:19 PM
Subject: Re: [IRCServices] cheers. ideas.


> its me again..
>
> the data storage, using sql brings a lot of new possibilitys, with real
> databases 3rd party programs/sites may use and change the information,
this
> is really interesting, develop internet portals based on the
users/channels
> information, search for users with html forms, retrieve/change password..
> integration is the main ideia.
>
> im currently helping a irc network called BrasNet (Brazil), the nick.db
have
> nothing more than 98 MB.. this _really_ stress the box.. with an indexed
> database the searches and querys about nicks and chans registrations and
> passwords authentication would be much more reliable!
>
> well.. post you comment..
>
> who is the services coding leader? Hi mr coder! (exchange ideas..)
>
> Cheers,
>
> Bruno Lacerda
> sniffer at sniffer.net
> http://sniffer.net
>
> ----- Original Message -----
> From: "Chris Wiest" <kwahraw at relic.net>
> To: <ircservices at Snow.shadowfire.org>
> Cc: <ircservices at Snow.shadowfire.org>
> Sent: Wednesday, October 11, 2000 10:09 AM
> Subject: Re: [IRCServices] cheers. ideas.
>
>
> > *shrug* perspectives and experience I suppose come into play here. While
> > it may be the o/s we are operating from, which is FreeBSD4.0 (I am
> > hesitant to move to 4.1, though the CD's are sitting on my desk at
> > work due to its relative newness, and some network issues I've had with
> > it on our development machine at work), 4.0 one would think would be
able
> > to keep mysql up and running.  The issue seems to come about with
multiple
> > query requests and attempts to place entries into the database
> > simultaneously.  Again, my point is an XML format would perhaps be the
> > better way to go, as it is not dependent on a 3rd party application
> > working properly.  Even if you have not had issues with the application
> > itself, there is still the exposure that a third party application (your
> > sql program) could crash, which on a philosophical level (putting aside
my
> > above mentioned personal problems with the application) is a bad way to
> > go. I am not saying not to go ahead with sql, I am just pointing out a
> > pretty clear downfall to doing so.
> >
> > --CDW
> >
> > On Wed, 11 Oct 2000, Scott Seufert wrote:
> >
> > > At 07:33 AM 10/11/2000 -0400, you wrote:
> > > >i debated, and even played with storing/retreiving to mysql.  The
> problem
> > > >that I've found is that you then deal with ensuring the sql program
is
> up
> > > >and running, and sql tends to crash (we actually have a sql based
> program
> > > >currently that has an average uptime of 2 to 3 days).  I don't know
if
> > > >anyone else has experienced this, however it seems to kinda be
> > > >standard.  We deal with 1600 to 2000 users simultaneous, they tend to
> get
> > > >pissy when our services go boom, and rightly so.  I'm not saying not
to
> > > >move to sql (though I'd say xml seems a better option), but I am
saying
> > > >that given sql's uptime, it can be an issue.
> > > >
> > > >--CDW
> > >
> > > <snip>
> > >
> > > In my experience I have seen quite the opposite, SQL tends to be quite
> > > stable. Offering reliable support for tens of thousands. This
experience
> > > includes mySQL and MS SQL.
> > >
> > > Scott Seufert
> > > aka katsklaw
> > > Server Admin
> > > Excalibre.ShadowFire.Org
> > >
> > >
> > > ---------------------------------------------------------------
> > > To unsubscribe, send email to majordomo at ender.shadowfire.org
> > > with "unsubscribe ircservices" in the body, without the quotes.
> > >
> >
> >
> > ---------------------------------------------------------------
> > To unsubscribe, send email to majordomo at ender.shadowfire.org
> > with "unsubscribe ircservices" in the body, without the quotes.
> >
>
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo at ender.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.