Thread Info
  • State Not Answered
  • Replies 8 replies
  • Subscribers 0 subscribers
  • Views 869 views
  • Users 0 members are here
Options
Suggested

[5.000] Logfile viewing very slow.

BarryG
I first reported problems like this in 4.720 beta, but they're still in 5.000:

The viewing of log files from "Local Log File Query" is VERY slow.

I believe this to be because there are no CRs or LFs between each line.
This is causing my browser to use massive amounts of RAM, and almost lock while loading the page. (Mozilla 1.6 on Win2k, PIII, 640MB RAM!)

Also, there are an excessive # of SPAN tags if you do NOT choose a filter.

I am a web programmer, I know what I'm talking about.
My complaints on 4.720 were apparently ignored.

Is no one else experiencing this problem?
Try viewing the PF logs this way.

Thanks,
Barry

    
Parents
  • 0
    I just tested in mine with the following:
    Time Span: Last 30 Days
    Logs: Packet Filter Only
    Mode: Filter
    Search Term: 80

    My results came very quickly with hundreds of lines. I am using Moz 1.6, WinXP, 1.6Ghz, 256MB RAM. The ASL box is a 2.5Ghz with 512MB RAM. Is the query I ran similiar to what you are running or something different?  
  • 0 in reply to Brent_Gay
    Try 1 or 2 days with no filter...
    After about 20 lines load, then each line takes a 1-2 seconds to display for me.

    I've also tried it on Mozilla 1.6 on 2.4GHz p4 on WinXP Pro.

    Thanks,
    Barry
  • 0 in reply to BarryG
    WOW! You were not kidding...I did that and Moz went to 99% CPU usage, the memory count kept going up, and it was slow!! Interesting???  

    But if you are wanting to view the entire log without any filtering I went to Local Logs -> Browse -> Packet Filter and click on the far most right icon to download/view the log I want to view in a .txt format. That seems to work fast. Maybe there should be some sort of input validation on that page that requires a serach string, it seems to work fast and clean when there is a search string entered.
  • 0 in reply to Brent_Gay
    Without the filter, it SHOULD give the same output as the download logs page, 

    As it doesn't, that's why I'm complaining.

    It isn't overloading the server, it's overloading the browser, because there are no CR/LFs.
    If you look at the HTML source of that page (if it ever loads), you can see that the data is ALL ONE LINE.

    I don't think IE suffers as much from this, but writing html like that is still wrong.

    If Astaro doesn't fix it, maybe I can fix it myself... it'd just be adding a '\n' to whatever perl script it is.
    ok... it's /var/wfe/querylog.pl
    Gee, it's encrypted or compiled or something! (it's not perl)

    ASTARO, PLEASE FIX THIS!!!!!
    IT'S A ONE-LINE FIX!!!

    Thanks,
    Barry
       
  • 0 in reply to BarryG
    OK, even though I can't reproduce it, I added line breaks to the output. This does not change behaviour in Firebird for me. This should be in 5.001, once it is out please tell me it if helped.

    /tom
     
Reply Children
Cookie Information Banner