[BACK]Return to searchcat.html CVS log [TXT] [DIR] Up to [LON-CAPA] / loncom / html / adm / help

Diff for /loncom/html/adm/help/searchcat.html between versions 1.1 and 1.2

version 1.1, 2001/08/28 12:13:52 version 1.2, 2001/11/28 17:00:07
Line 186  the specific resource.  Advanced users c Line 186  the specific resource.  Advanced users c
 <h3>6. Notes on software architecture</h3>  <h3>6. Notes on software architecture</h3>
 <br clear='all' />  <br clear='all' />
 <p>  <p>
   LON-CAPA is meant to distribute A LOT of educational content
   to A LOT of people.  It is ineffective to directly rely on contents
   within the ext2 filesystem to be speedily scanned for 
   on-the-fly searches of content descriptions.  (Simply put,
   it takes a cumbersome amount of time to open, read, analyze, and
   close thousands of files.)
   </p>
   <p>
   The solution is to hash-index various data fields that are
   descriptive of the educational resources on a LON-CAPA server
   machine.  Descriptive data fields are referred to as
   "metadata".  The question then arises as to how this metadata
   is handled in terms of the rest of the LON-CAPA network
   without burdening client and daemon processes.  I now
   answer this question in the format of Problem and Solution
   below.
   </p>
   <p>
   <pre>
   PROBLEM SITUATION:
   
     If Server A wants data from Server B, Server A uses a lonc process to
     send a database command to a Server B lond process.
       lonc= loncapa client process    A-lonc= a lonc process on Server A
       lond= loncapa daemon process
   
                    database command
       A-lonc  --------TCP/IP----------------> B-lond
   
     The problem emerges that A-lonc and B-lond are kept waiting for the
     MySQL server to "do its stuff", or in other words, perform the conceivably
     sophisticated, data-intensive, time-sucking database transaction.  By tying
     up a lonc and lond process, this significantly cripples the capabilities
     of LON-CAPA servers. 
   
     While commercial databases have a variety of features that ATTEMPT to
     deal with this, freeware databases are still experimenting and exploring
     with different schemes with varying degrees of performance stability.
   
   THE SOLUTION:
   
     A separate daemon process was created that B-lond works with to
     handle database requests.  This daemon process is called "lonsql".
   
     So,
                   database command
     A-lonc  ---------TCP/IP-----------------> B-lond =====> B-lonsql
            <---------------------------------/                |
              "ok, I'll get back to you..."                    |
                                                               |
                                                               /
     A-lond  <-------------------------------  B-lonc   <======
              "Guess what? I have the result!"
   
     Of course, depending on success or failure, the messages may vary,
     but the principle remains the same where a separate pool of children
     processes (lonsql's) handle the MySQL database manipulations.
   </pre>
 </p>  </p>
 <br />&nbsp;<br />  <br />&nbsp;<br />
 <a name='limitations' />  <a name='limitations' />
Removed from v.1.1  
changed lines
  Added in v.1.2

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>