On Thu 03 May 2001 22:35, you wrote:
> And now to have the full picture of the mess, let's say you
> have 30
> web-sites with thousands of visitors.
> I'm going to come to the developers' defence on this. As it stands,
> Analog performs all of its processing in memory. This enhancement is
> just short of requiring a database or series of temporary files. We
> already have the very major potential for conflicts involving pie
> charts when two users are running simultaneously. Imagine the chaos
> if two or three users are trying to process against a series of files
> in /tmp or some other location. Unix users have it over NT users in
He he he! What if your users use "gcc" the same time? Will compiling
crash? ;-)
> that filenames can be suffixed with the process id. (Yes, you can do
> the same with NT.) Is it worth the expense of already valueable disk
> space to stream copies of 20-30GB logs into temporary storage?
Who did this? Indeed is a wast of space. But temporary files are not
on spliting files, but for intermediary results. Which are small enough
to keep on disk between succesive processing but big enough to not keep
it in memory.
If you want to be fair, just say the solution (whithout requiring to
split files). I tell somtehing: just try to split 600M in chunks on your
system and tell me if it not enter on trashing (supose you have Linux,
I don't know how Solaris, HP-UX etc. handle disk buffers).
So, it's more practicaly to eliminate file spliting overhead. Again, I
repeat it's a pain to split 600M or more. Seeking on file is only read
so disk traffic is more reduced.
Also, as I said user can choose. If it want e.g UNIQUEIP options, then
analog main parsing loop will take in account this. I don't know analog
internals so I just make suppositions. If introducing this options
break many parts in analog structure, then it must be biased if must
be implemented soon or not at all.
kind regards,
--
Claudiu Costin
<[EMAIL PROTECTED]>
+------------------------------------------------------------------------
| This is the analog-help mailing list. To unsubscribe from this
| mailing list, go to
| http://lists.isite.net/listgate/analog-help/unsubscribe.html
|
| List archives are available at
| http://www.mail-archive.com/[email protected]/
| http://lists.isite.net/listgate/analog-help/archives/
| http://www.tallylist.com/archives/index.cfm/mlist.7
+------------------------------------------------------------------------
