1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] cheers. ideas.
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To=000401c036bd%2411e3e240%240100a8c0%40sunnyline.co.za">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000877.html">
11 <LINK REL=
"Next" HREF=
"000881.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] cheers. ideas.
</H1>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To=000401c036bd%2411e3e240%240100a8c0%40sunnyline.co.za"
17 TITLE=
"[IRCServices] cheers. ideas.">&quot
19 <I>Sun Oct
15 10:
15:
11 PDT
2000</I>
21 <LI>Previous message:
<A HREF=
"000877.html">[IRCServices] cheers. ideas.
23 <LI>Next message:
<A HREF=
"000881.html">[IRCServices] cheers. ideas.
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#879">[ date ]
</a>
27 <a href=
"thread.html#879">[ thread ]
</a>
28 <a href=
"subject.html#879">[ subject ]
</a>
29 <a href=
"author.html#879">[ author ]
</a>
34 <PRE>><i> > Services is a READ ONCE, WRITE MANY application. If you make changes to
36 </I>><i> > data in the underlying datastore, be it a database, binary file or text
37 </I>><i> > file, the changes would be lost at the next database save.
39 </I>><i> *shrugs*. Andrew, it will be lost because of the way data is CURRENTLY
40 </I>><i> saved in the database. Do you mean to tell me now that if I have a SQL
41 </I>><i> database, access the database from two applications, and update the
42 </I>><i> information from one. Do you want to tell me the information
43 </I>><i> change is not
44 </I>><i> going to reflect in the second application? Maybe not if you dont ask for
45 </I>><i> it again, but SURE the information IS going to be there at the next SELECT
46 </I>><i> from the database. Which is more than adequate in the way
47 </I>><i> Services needs to
48 </I>><i> retrieve its information from the databases.
50 I was referring to the question/suggestion of allowing other applications to
51 update the database themselves. Those changes would be lost.
53 ><i> > Services would require a lot of work to make it support proper
54 </I>><i> querying of
56 </I>><i> > database. The performance hit services would take would outweigh the
58 </I>><i> > imho. If one were to do it properly, with multiple threads loading only
60 </I>><i> > information needed to service the users and channels currently online,
61 </I>><i> > things would definately be better. However, let's be honest,
62 </I>><i> this requires
64 </I>><i> > lot of developement, skills and time.
66 </I>><i> Once again. How can you talk about the performance WITHOUT bothering to
67 </I>><i> test this? Don't rub of a suggestion / idea just because you are
69 </I>><i> I made my first post, I've shown you my results. I ask again, do you have
70 </I>><i> similar results for the databases currently in use? No, I didn't
73 I'm talking from indirect experience with other systems that use this
74 approach. If you're so sure of the benefits, please feel free to implement
75 them. I'm just stating what I think with regard to the time and resources at
78 ><i> > What we should focus on is writing an interface for Services that allows
79 </I>><i> > external apps to communicate with it.
81 </I>><i> What we should be focusing on, is to analyse services, and find
82 </I>><i> out EXACTLY
83 </I>><i> WHAT and WHERE the bottlenecks in services are. Sure, the databases might
84 </I>><i> be one of them, but wouldn't it be ALLOT easier if we know WHERE in the
85 </I>><i> databases the problem lies? For one, what would happen if you created an
86 </I>><i> index on the databases for one thing....
88 I have already done profiling on a
10'
000 user network. Improving findnick()
89 would make a huge difference in terms of performance. I hope to make these
90 changes in the near future - again, as time permits.
92 ><i> > Back to your point about Brasnet,
98MB is a lot. However, it's
93 </I>><i> not totally
94 </I>><i> > unreasonable. The thing I'd guess that is really taking a hit
95 </I>><i> is the CPU.
96 </I>><i> > The algorithms were never meant to handle so much data. I am definately
97 </I>><i> > looking to improve the key ones.
99 </I>><i> >From a SQL based view, its bizzare, sorry. Once again aswell,
100 </I>><i> it wont be a
101 </I>><i> bottle neck on the CPU either. But hey, what do I know...
103 But the fact is that we currently have a flatfile database and that
104 improving the lookup functions currently in use would require a lot less
105 effort and time than implementing proper RDMBS support.
110 ---------------------------------------------------------------
111 To unsubscribe, send email to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org
</A>
112 with
"unsubscribe ircservices
" in the body, without the quotes.
121 <LI>Previous message:
<A HREF=
"000877.html">[IRCServices] cheers. ideas.
123 <LI>Next message:
<A HREF=
"000881.html">[IRCServices] cheers. ideas.
125 <LI> <B>Messages sorted by:
</B>
126 <a href=
"date.html#879">[ date ]
</a>
127 <a href=
"thread.html#879">[ thread ]
</a>
128 <a href=
"subject.html#879">[ subject ]
</a>
129 <a href=
"author.html#879">[ author ]
</a>
projects / irc.git / blob