in reply to File download statistics parsing

I'm not as familiar with Squid logs as I used to be with Apache logs - is the numeric value before the TCP_MISS:DIRECT the amount downloaded, or the final byte offset of the range of bytes downloaded? If the latter is the case, your plan will work, and the logs you show here could mean that someone started a download and the download was interrupted and then resumed. If the former is the case, it means that the user started a download, the download failed, and the user started the download again from the beginning, succeeding the second time - it can't ever represent a resumed download, and you'll never count them. You'll also never count files downloaded using download accelerators, which request multiple byte ranges of a file in parallel.

Replies are listed 'Best First'.
Re: Re: File download statistics parsing
by bean (Monk) on Aug 07, 2003 at 22:58 UTC
    Never mind my previous post - I see that you know about the issue raised in it already. Guess I should have read all the replies first...

    However,
    although it won't help you analyse the current logs, if you could customize the logs to show the final byte offset of the range you could count a complete file download if the final byte offset matched the size of the actual file. There would probably be exceptions (I'm sure there are some perverted user agents that ask for the end of the file first) but it would be as accurate as any other method and a lot easier (I'm all about easier). Unfortunately, my lack of familiarity with Squid keeps me from knowing if it's possible to customize the logs in this way.
[reply]

In Section Seekers of Perl Wisdom