[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.
>
> *shrugs*.  Andrew, it will be lost because of the way data is CURRENTLY
> saved in the database.  Do you mean to tell me now that if I have a SQL
> database, access the database from two applications, and update the
> information from one.  Do you want to tell me the information
> change is not
> going to reflect in the second application?  Maybe not if you dont ask for
> it again, but SURE the information IS going to be there at the next SELECT
> from the database.  Which is more than adequate in the way
> Services needs to
> retrieve its information from the databases.

I was referring to the question/suggestion of allowing other applications to
update the database themselves. Those changes would be lost.

> > 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.
>
> Once again.  How can you talk about the performance WITHOUT bothering to
> test this?  Don't rub of a suggestion / idea just because you are
> not sure.
> I made my first post, I've shown you my results.  I ask again, do you have
> similar results for the databases currently in use?  No, I didn't
> think so.

I'm talking from indirect experience with other systems that use this
approach. If you're so sure of the benefits, please feel free to implement
them. I'm just stating what I think with regard to the time and resources at
my disposal.

> > What we should focus on is writing an interface for Services that allows
> > external apps to communicate with it.
>
> What we should be focusing on, is to analyse services, and find
> out EXACTLY
> WHAT and WHERE the bottlenecks in services are.  Sure, the databases might
> be one of them, but wouldn't it be ALLOT easier if we know WHERE in the
> databases the problem lies?  For one, what would happen if you created an
> index on the databases for one thing....

I have already done profiling on a 10'000 user network. Improving findnick()
would make a huge difference in terms of performance. I hope to make these
changes in the near future - again, as time permits.

> > 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.
>
> >From a SQL based view, its bizzare, sorry.  Once again aswell,
> it wont be a
> bottle neck on the CPU either.  But hey, what do I know...

But the fact is that we currently have a flatfile database and that
improving the lookup functions currently in use would require a lot less
effort and time than implementing proper RDMBS support.

Andrew


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