High Latency Using HTTP PRoXY – ZeroShell Bridge

Home Page Forums Network Management ZeroShell High Latency Using HTTP PRoXY – ZeroShell Bridge

This topic contains 13 replies, has 0 voices, and was last updated by  SupaJ 9 years ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #42468

    SupaJ
    Member

    Hi,
    I have zeroshell configured as a brigde – which works fine. However, when I activate the HTTP proxy, web browsing on clients connected to zeroshell is very slow. Sometimes pages even time-out. Can anyone help? Cheers.

    #50561

    ppalias
    Member

    Could it be that cpu is stressed with the use of proxy?

    #50562

    SupaJ
    Member

    It’s weekend and I don’t have access to the PC right now, hence I can’t check the CPU usage when the HTTP proxy is on – notwithstanding, it’s a 1.8GHz P4 w/ 256MB RAM. Shouldn’t that be more than sufficient to run the HTTP Proxy? Thanks.

    #50563

    ppalias
    Member

    Now that you mention the server specs it should be a problem, but I thought I should ask anyway.

    #50564

    SupaJ
    Member

    Any other suggestions? Does the HTTP proxy depend on any other service, e.g. DNS? What could be causing the slow browsing when it is turned on? It normally starts with a small latency and then the delay gradually increases over a few minutes – until web browsing becomes almost unbearable through it. Could it be the antivirus? How do I turn it off? Thanks.

    #50565

    ppalias
    Member

    You didn’t mention if the CPU load is ok when the proxy is turned on. It could be the “Access Logging (check the law in your country)” if it is logging anything. Try to switch it to “Only URL containing virus”.

    #50566

    SupaJ
    Member

    @ppalias wrote:

    You didn’t mention if the CPU load is ok when the proxy is turned on.

    I checked my CPU log – it’s hardly ever above 4%.
    @ppalias wrote:

    It could be the “Access Logging (check the law in your country)” if it is logging anything. Try to switch it to “Only URL containing virus”.

    I had already done that – switch it to “Only URL containing virus”.

    Quick question: I am running a bridge but i am capturing on ETH0 and ETH1 but not BR0. Is this correct?

    Edit: Additionally I noticed the following:
    CPU usage w/o HTTP proxy: 4%
    CPU usage w/ HTTP proxy: 8%

    RAM usage w/o HTTP Proxy: 84MB
    RAM usage w/ HTTP Proxy: 174MB (max RAM on PC is 256MB)

    Can the above factors hinder the performance of the HTTP Proxy?

    #50567

    ppalias
    Member

    My guess is that you should be capturing on BRIDGE interface. CPU usage and memory usage seem not to be the bottleneck. Try to switch capturing the BRIDGE interface only and make sure you capture only one way, e.g use source address of your local lan.

    #50568

    SupaJ
    Member

    @ppalias wrote:

    My guess is that you should be capturing on BRIDGE interface. CPU usage and memory usage seem not to be the bottleneck. Try to switch capturing the BRIDGE interface only and make sure you capture only one way, e.g use source address of your local lan.

    I switched to bridge as per your suggestion – still no improvement. Web pages continue to load very slowly when HAVP is activated – logging is turn off(only logs webpages with virus), image scanning is also off. Is there a way for me to temporarily turn off the antivirus and leave the http proxy on?

    #50569

    ppalias
    Member

    I don’t think this can be done, I can see that the selection is disabled.
    Try this one; open a shell and run the top command. Start using the proxy and check if any process seems to be taking too much memory or CPU. Also open a new shell and run iptraf and select general interface statistics. Check what is the network utilization while you turn proxy on and off.

    #50570

    SupaJ
    Member

    @ppalias wrote:

    I don’t think this can be done, I can see that the selection is disabled.
    Try this one; open a shell and run the top command. Start using the proxy and check if any process seems to be taking too much memory or CPU. Also open a new shell and run iptraf and select general interface statistics. Check what is the network utilization while you turn proxy on and off.

    Here is my TOP and IPTRAF results with HAVP turn on. Is there anything abnormal with it? I am not too familiar with TOP, but I see three PID’s for HAVP, each one consuming about 32%RAM. Are these separate processes or is it just one?

    #50571

    ppalias
    Member

    If your internet line is not something close to 3,5Mbps then most likely havp is eating up most of your memory. I am not using proxy server on ZS cause it makes some streaming radios, that I listen to, stop working. Try to upgrade the memory for a start.

    #50572

    SupaJ
    Member

    @ppalias wrote:

    If your internet line is not something close to 3,5Mbps then most likely havp is eating up most of your memory. I am not using proxy server on ZS cause it makes some streaming radios, that I listen to, stop working. Try to upgrade the memory for a start.

    It finally worked! – I transferred Zeroshell to a machine with more resources: P4 2.8GHz, 1GB RAM. Apparently is was a lack of RAM causing HAVP to run slow. Thanks ppalias.

    It appears that HAVP can’t catch HTTPS. Is this correct? What can be done in this case?

    #50573

    ppalias
    Member

    You can verify it with running the command

    iptables -L -v
    iptables -t nat -L -v

    If there is a rule only for port 80 requests then it captures only HTTP. Most likely adding the same rules for port 443 as well would fix it, but I’m not sure if it would cause a problem on the web interface of ZS.

    #50574

    lonetorus
    Member

    i was having the same kind of issue, bridged ZS with proxy being slow, turns out that traffic from the proxy was getting cought in the very low bandwidth default qos class, in any case, check that if you are having this issue too and the above posts didnt help.

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.