software/RELEASES/ircservices/achurch.org/services/lists/ircservices/2000/000877.html

   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 &lt;<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">andrewk at icon.co.za</A>&gt;
  38 To: &lt;<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at Snow.shadowfire.org</A>&gt;
  39 Sent: Wednesday, October 11, 2000 5:44 PM
  40 Subject: Re: [IRCServices] cheers. ideas.
  41
  42
  43 &gt;<i> Services is a READ ONCE, WRITE MANY application. If you make changes to
  44 </I>the
  45 &gt;<i> data in the underlying datastore, be it a database, binary file or text
  46 </I>&gt;<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 &gt;<i> Services would require a lot of work to make it support proper querying of
  58 </I>a
  59 &gt;<i> database. The performance hit services would take would outweigh the
  60 </I>benefit
  61 &gt;<i> imho. If one were to do it properly, with multiple threads loading only
  62 </I>the
  63 &gt;<i> information needed to service the users and channels currently online,
  64 </I>&gt;<i> things would definately be better. However, let's be honest, this requires
  65 </I>a
  66 &gt;<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 &gt;<i> What we should focus on is writing an interface for Services that allows
  74 </I>&gt;<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 &gt;<i> Back to your point about Brasnet, 98MB is a lot. However, it's not totally
  83 </I>&gt;<i> unreasonable. The thing I'd guess that is really taking a hit is the CPU.
  84 </I>&gt;<i> The algorithms were never meant to handle so much data. I am definately
  85 </I>&gt;<i> looking to improve the key ones.
  86 </I>
  87 &gt;<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 &quot;unsubscribe ircservices&quot; 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>