Re: [squid-users] Problem publishing on Facebook via Squid 3.1.2

On 11/27/2012 6:39 PM, Delisle, Marc wrote:
> Hello,
> I am running 3.1.2 on a SUSE Linux Enterprise Server box (8 GB RAM) for 2700 clients, with 6500 HTTP requests per minute. This Squid instance is doing forward proxy and intercept too.
>
> The problem is when users are trying to use the publish feature on Facebook (we have a few corporate pages): the publish operation freezes (but only during office hours; it works fine early in the morning, for example).
>
> To troubleshoot, I installed the same OS and Squid version on a virtual machine. I asked these users to point to this proxy instance and all is fine (still during office hours).
>
> Maybe this Squid instance is overloaded? Is it a bad idea to be running Squid on box that is routing all outgoing traffic? Could it help to run a second instance of Squid on this box?
>
> Thanks,
> Marc Delisle

Hello Marc,

8GB is not the reason which you can get this problem from.
If you will be more specific about the environment and hardware
peripherals we can maybe assume couple things.

For now the basic thing is that your server software is OLD and not
up-to-date with the latest patches.
The current 3.1 version is 3.1.21 which will might solve this specific
problem you are having.

This amount (about 130 per sec) of requests should not move a muscle for
squid(from experience).
You can use this amount of connections on an INTEL atom D410 and D525
with 8GB ram and you should not have any problem with it.
The major culprits for slowdowns in such situation can be caused by:
- High HDD access(r\w) to SATA drives on software raid(any)
- Facebook or other servers on the way that identify your traffic as
abusing and\or as DOS.
- Bug.
- many others.

My suggestion is to first try remove any disk access to make sure this
is not the culprit.
Force the basic "none" for access logs and also make the proxy as mem
only cache by disabling all the cache_dir.

It will give you a nice view on your server hardware performance else
then the HDD.

As I mentioned before this is a very OLD version of SQUID and you better
give a test fly to 3.2.3 stable version which improves squid in any way
I can think of.

About routing + squid, Depends on the hardware.
Routing by itself wont be too much in this specific case by my experience.
even if you will hold some BGP or other server it should hold it for
2700 users pretty easily.

NAT is also a thing in this scenario which if exists for 2700 users you
will be having a lot of problems with it.

If you can check for the server stats in these hours it would be good to
see the wait memory and cpu usage.
If you have a SWAP being used it could point you to the source of the
problem.

After all the above data will be gathered you will have a more solid
ground towards the Solution.

Regards,
Eliezer

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
sip:ngtech_at_sip2sip.info
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il