To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.dev.org.ldrawOpen lugnet.cad.dev.org.ldraw in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / Organizations / LDraw / 660
659  |  661
Subject: 
Re: OMR Planning - Almost There
Newsgroups: 
lugnet.cad.dev.org.ldraw
Date: 
Tue, 4 Jan 2000 19:43:31 GMT
Viewed: 
810 times
  
In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen writes:
[...] And one of my friends is trying to convince me that it is faster
to serve pages from a database than from disk, [...]

I have to wonder about that assertion in a really skeptical way.  In either
case, assuming the filesystem and the database aren't poorly written, the
amount of RAM in the server is really the gating factor.

If you have 50 MB of static files and 256 MB of RAM, for instance, and all
of those 50 MB of files fit into the filesystem cache, then under a heavy
load (the only time where speed would actually make a difference), it's not
going to be any faster to fetch the files out of a database than it is to
fetch them out of the filesystem cache in RAM.  In fact, even if you maintain
a persistent DB connection across multiple HTTP requests, if there's anything
to be dynamically created at all in the returned content, static files are
the fastest way, always.  (Except of course if you have a custom server that
bypasses even the filesystem or the DBMS and hard-codes the data in the text
segment. :-)

When a database is faster compared to a typical filesystem is when the
filesystem hasn't been defragged or hasn't been magically organized for
fast random access, and then only when the source data doesn't fit in
available RAM.  So if you're serving lots (hundreds of thousands or more)
of relatively small objects (say, 16KB or smaller) from a very large set of
objects (say, more than 100 MB total), and you don't have a lot of RAM, then
a DBMS may be faster than the native filesystem.  Otherwise, heck, go with
whatever is the least headache.

--Todd



Message has 2 Replies:
  Re: OMR Planning - Almost There
 
(...) Yes. That AND the sort of data you are fetching. In certain cases, a DB engine that has cached the results of queries, coupled with a requesting program that can use the results straightaway, can be faster than a raw filesystem, even if the (...) (25 years ago, 4-Jan-00, to lugnet.cad.dev.org.ldraw)
  Re: OMR Planning - Almost There
 
(...) (rereading what I wrote) Uh, durrr, that came out as hogwash, didn't it. I meant, if the pages that are created dynamically happen to come out the same as though they had been served statically (IOW, if it's static content generated (...) (25 years ago, 4-Jan-00, to lugnet.cad.dev.org.ldraw)

Message is in Reply To:
  Re: OMR Planning - Almost There
 
Tim: [ About instructions from non-Lugnuts. ] I wouldn't let non-Lugnuts post to Lugnet through ldraw.org. We should rather let them upload to ldraw.org, and let the OMR editors post the instructions to lugnet.cad.dat.models.sets if they qualify. To (...) (25 years ago, 4-Jan-00, to lugnet.cad.dev.org.ldraw)

14 Messages in This Thread:





Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR