[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices / 2000 / 000877.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [IRCServices] cheers. ideas.
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To=">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="000854.html">
   <LINK REL="Next"  HREF="000879.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[IRCServices] cheers. ideas.</H1>
    <B>Chris Knipe</B> 
    <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To="
       TITLE="[IRCServices] cheers. ideas.">cgknipe at mweb.co.za
       </A><BR>
    <I>Sat Oct 14 13:26:32 PDT 2000</I>
    <P><UL>
        <LI>Previous message: <A HREF="000854.html">[IRCServices] Desperate Problems
</A></li>
        <LI>Next message: <A HREF="000879.html">[IRCServices] cheers. ideas.
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#877">[ date ]</a>
              <a href="thread.html#877">[ thread ]</a>
              <a href="subject.html#877">[ subject ]</a>
              <a href="author.html#877">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>*shrugs*

----- Original Message -----
From: Andrew Kempe &lt;<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">andrewk at icon.co.za</A>&gt;
To: &lt;<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at Snow.shadowfire.org</A>&gt;
Sent: Wednesday, October 11, 2000 5:44 PM
Subject: Re: [IRCServices] cheers. ideas.


&gt;<i> Services is a READ ONCE, WRITE MANY application. If you make changes to
</I>the
&gt;<i> data in the underlying datastore, be it a database, binary file or text
</I>&gt;<i> file, the changes would be lost at the next database save.
</I>
*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.

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

&gt;<i> What we should focus on is writing an interface for Services that allows
</I>&gt;<i> external apps to communicate with it.
</I>
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....

&gt;<i> Back to your point about Brasnet, 98MB is a lot. However, it's not totally
</I>&gt;<i> unreasonable. The thing I'd guess that is really taking a hit is the CPU.
</I>&gt;<i> The algorithms were never meant to handle so much data. I am definately
</I>&gt;<i> looking to improve the key ones.
</I>
&gt;<i>From a SQL based view, its bizzare, sorry.  Once again aswell, it wont be a
</I>bottle neck on the CPU either.  But hey, what do I know...

---
Regards,
Chris Knipe
Cell: (083) 430-8151


---------------------------------------------------------------
To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A>
with &quot;unsubscribe ircservices&quot; in the body, without the quotes.


</PRE>

<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="000854.html">[IRCServices] Desperate Problems
</A></li>
	<LI>Next message: <A HREF="000879.html">[IRCServices] cheers. ideas.
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#877">[ date ]</a>
              <a href="thread.html#877">[ thread ]</a>
              <a href="subject.html#877">[ subject ]</a>
              <a href="author.html#877">[ author ]</a>
         </LI>
       </UL>

</body></html>
Commit	Line	Data
3bd189cb JR	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
	2	<HTML>
	3	<HEAD>
	4	<TITLE> [IRCServices] cheers. ideas.
	5	</TITLE>
	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=">
	8	<META NAME="robots" CONTENT="index,nofollow">
	9	<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
	10	<LINK REL="Previous" HREF="000854.html">
	11	<LINK REL="Next" HREF="000879.html">
	12	</HEAD>
	13	<BODY BGCOLOR="#ffffff">
	14	<H1>[IRCServices] cheers. ideas.</H1>
	15	<B>Chris Knipe</B>
	16	<A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To="
	17	TITLE="[IRCServices] cheers. ideas.">cgknipe at mweb.co.za
	18	</A><BR>
	19	<I>Sat Oct 14 13:26:32 PDT 2000</I>
	20	<P><UL>
	21	<LI>Previous message: <A HREF="000854.html">[IRCServices] Desperate Problems
	22	</A></li>
	23	<LI>Next message: <A HREF="000879.html">[IRCServices] cheers. ideas.
	24	</A></li>
	25	<LI> <B>Messages sorted by:</B>
	26	<a href="date.html#877">[ date ]</a>
	27	<a href="thread.html#877">[ thread ]</a>
	28	<a href="subject.html#877">[ subject ]</a>
	29	<a href="author.html#877">[ author ]</a>
	30	</LI>
	31	</UL>
	32	<HR>
	33	<!--beginarticle-->
	34	<PRE>shrugs
	35
	36	----- Original Message -----
	37	From: Andrew Kempe <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">andrewk at icon.co.za</A>>
	38	To: <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at Snow.shadowfire.org</A>>
	39	Sent: Wednesday, October 11, 2000 5:44 PM
	40	Subject: Re: [IRCServices] cheers. ideas.
	41
	42
	43	><i> Services is a READ ONCE, WRITE MANY application. If you make changes to
	44	</I>the
	45	><i> data in the underlying datastore, be it a database, binary file or text
	46	</I>><i> file, the changes would be lost at the next database save.
	47	</I>
	48	shrugs. Andrew, it will be lost because of the way data is CURRENTLY
	49	saved in the database. Do you mean to tell me now that if I have a SQL
	50	database, access the database from two applications, and update the
	51	information from one. Do you want to tell me the information change is not
	52	going to reflect in the second application? Maybe not if you dont ask for
	53	it again, but SURE the information IS going to be there at the next SELECT
	54	from the database. Which is more than adequate in the way Services needs to
	55	retrieve its information from the databases.
	56
	57	><i> Services would require a lot of work to make it support proper querying of
	58	</I>a
	59	><i> database. The performance hit services would take would outweigh the
	60	</I>benefit
	61	><i> imho. If one were to do it properly, with multiple threads loading only
	62	</I>the
	63	><i> information needed to service the users and channels currently online,
	64	</I>><i> things would definately be better. However, let's be honest, this requires
65	</I>a
66	><i> lot of developement, skills and time.
67	</I>
68	Once again. How can you talk about the performance WITHOUT bothering to
69	test this? Don't rub of a suggestion / idea just because you are not sure.
70	I made my first post, I've shown you my results. I ask again, do you have
71	similar results for the databases currently in use? No, I didn't think so.
72
73	><i> What we should focus on is writing an interface for Services that allows
74	</I>><i> external apps to communicate with it.
75	</I>
76	What we should be focusing on, is to analyse services, and find out EXACTLY
77	WHAT and WHERE the bottlenecks in services are. Sure, the databases might
78	be one of them, but wouldn't it be ALLOT easier if we know WHERE in the
79	databases the problem lies? For one, what would happen if you created an
80	index on the databases for one thing....
81
82	><i> Back to your point about Brasnet, 98MB is a lot. However, it's not totally
83	</I>><i> unreasonable. The thing I'd guess that is really taking a hit is the CPU.
84	</I>><i> The algorithms were never meant to handle so much data. I am definately
85	</I>><i> looking to improve the key ones.
86	</I>
87	><i>From a SQL based view, its bizzare, sorry. Once again aswell, it wont be a
88	</I>bottle neck on the CPU either. But hey, what do I know...
89
90	---
91	Regards,
92	Chris Knipe
93	Cell: (083) 430-8151
94
95
96
97
98	---------------------------------------------------------------
99	To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A>
100	with "unsubscribe ircservices" in the body, without the quotes.
101
102
103	</PRE>
104
105	<!--endarticle-->
106	<HR>
107	<P><UL>
108	<!--threads-->
109	<LI>Previous message: <A HREF="000854.html">[IRCServices] Desperate Problems
110	</A></li>
111	<LI>Next message: <A HREF="000879.html">[IRCServices] cheers. ideas.
112	</A></li>
113	<LI> <B>Messages sorted by:</B>
114	<a href="date.html#877">[ date ]</a>
115	<a href="thread.html#877">[ thread ]</a>
116	<a href="subject.html#877">[ subject ]</a>
117	<a href="author.html#877">[ author ]</a>
118	</LI>
119	</UL>
120
121	</body></html>