# [SQUID] Velocidad de envio de datos cacheados lenta

## Txema

Aquí estoy otra vez con squid ^^

Esta vez he notado que cuando squid me envía los archivos que tiene en la caché la velocidad no pasa de ~ 1 MB/s cuando he comprobado que mi LAN admite hasta 10MB/s mínimo. Además esta velocidad se parece sospechosamente a mi velocidad de descarga de internet (WAN).

La descarga estoy seguro de que no se produce de internet porque en ppp0 no hay apenas movimiento mientras que en br0 hay un gran pico en la velocidad de envío (hacia eth0 de mi pc), el problema es que si esta es la máxima velocidad que alcanza squid me sirve de poco, ya que sin él tendría la misma velocidad...

¿Sabéis algo de esto?

----------

## esteban_conde

 *Txema wrote:*   

> Esta vez he notado que cuando squid me envía los archivos que tiene en la caché la velocidad no pasa de ~ 1 MB/s cuando he comprobado que mi LAN admite hasta 10MB/s mínimo.

 

No sabria decirte pero pudiera ser que 1MB/s = 8Mb/s aunque puede que cueste averiguar si es así.

----------

## Inodoro_Pereyra

Txema, 1MB de bajada o 1Mb de bajada? (Por Byte y bit)

Una red cableada de 100mbps (megabits por segundo) alcanza una velocidad teórica de 12500MBps (megabytes por segundo).

El sistema operativo muestra las unidades en bytes y no en bits, con los que si tu velocidad de bajada es de 1 megabit (128 kilobits por segundo) y -lo que sea que uses para medir- indica 1 megabyte de tasa de transferencia, pues entonces estas moviendo información desde el caché de Squid como mínimo unas 8 veces mas rápido.

Pruebita facil, buscando algún archivo grande en internet bajandolo dos veces con squid de por medio:

```
~ # wget http://xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com/2008/08/boardmaxtordiamondplus980gb.jpg

--2009-07-02 22:13:04--  http://xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com/2008/08/boardmaxtordiamondplus980gb.jpg

Resolving xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com... 76.74.255.125, 76.74.254.125, 72.233.69.12, ...

Connecting to xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com|76.74.255.125|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 1133672 (1.1M) [image/jpeg]

Saving to: `boardmaxtordiamondplus980gb.jpg'

100%[==========================================================>] 1,133,672   19.5K/s   in 1m 42s  

2009-07-02 22:14:55 (10.8 KB/s) - `boardmaxtordiamondplus980gb.jpg' saved [1133672/1133672]

~ # wget http://xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com/2008/08/boardmaxtordiamondplus980gb.jpg

--2009-07-02 22:15:04--  http://xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com/2008/08/boardmaxtordiamondplus980gb.jpg

Resolving xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com... 72.233.69.13, 74.200.244.61, 72.233.69.12, ...

Connecting to xdr5tgy7ujmcft67uhgbvvgy75thn.files.wordpress.com|72.233.69.13|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 1133672 (1.1M) [image/jpeg]

Saving to: `boardmaxtordiamondplus980gb.jpg.1'

100%[==========================================================>] 1,133,672   --.-K/s   in 0.09s   

2009-07-02 22:15:04 (11.5 MB/s) - `boardmaxtordiamondplus980gb.jpg.1' saved [1133672/1133672]
```

Desde internet:

100%[==========================================================>] 1,133,672   19.5K/s   in 1m 42s  

Al segundo intento, desde el caché:

100%[==========================================================>] 1,133,672   --.-K/s   in 0.09s   

Salud!

----------

## Txema

Vamos a ver, las medidas son exactamente como indiqué, B de bytes no b de bits, pot lo tanto tengo una velocidad real de bajada de ~ 1 MB/s (o un poco menos, depende de la saturación de mi central) y en la red puedo recibir y enviar archivos a 10 MB/s

Lo que uso siempre para medir (además de las descargas desde firefox,konqueror,wget o firefox como es lógico) el monitor gkrellm que me da las medidas en KB/s (no Kb/s) y cuando supera los 1024 pues me lo da en MB/s (no Mb/s)

Y por ello mi duda.

Saludos  :Wink: 

----------

## Inodoro_Pereyra

En ese caso algo anda mal en tu Squid. No puede ser... Cual es el tamaño maximo de archivo que estás cacheando y cuanto tiene de tamaño total tu cache_dir?

En cuanto al formato del caché, que estás usando? Usas delay_pools?

Salud!

----------

## Txema

Algunos datos son estos:

 *Quote:*   

> cache_dir aufs /var/cache/squid 3100 16 256
> 
> maximum_object_size 8096 KB
> 
> #Default:
> ...

 

El formato de /var es ext4 con un commit=120 (la verdad es que no he hecho ninguna prueba con respecto a ext2, así que no sé si esto ha mejorado o no la velocidad)

Quizás debería aumentar al tamaño máximo cacheado.

P.D: con un archivo de unos 5MB ->

 *Quote:*   

> chema@gentoo ~ $ wget http://handbrake.fr/rotation.php?file=HandBrake-0.9.3-Ubuntu_CLI_i386.tgz
> 
> --2009-07-03 18:38:54--  http://handbrake.fr/rotation.php?file=HandBrake-0.9.3-Ubuntu_CLI_i386.tgz
> 
> Resolviendo handbrake.fr... 91.121.74.28
> ...

 

Parece que intenta acelerar, pero la segunda vez está funcionando ppp0 para recibir de internet (precisamente a esa misma velocidad) y br0 enviando a mi pc.

Sin embargo, con el archivo que has usado tú de prueba me lo envía la segunda vez a 2-3 MB/s (normal porque es tan pequeño que no alcanza la velocidad máxima) y en ppp0 no hay actividad...Last edited by Txema on Sat Jul 04, 2009 11:23 am; edited 1 time in total

----------

## Inodoro_Pereyra

Esta es la configuración del Squid que estoy usando para probar:

```
acl manager proto cache_object

acl localhost src 127.0.0.1/32

acl to_localhost dst 127.0.0.0/8

acl localnet src 10.0.0.0/8   # RFC1918 possible internal network

acl localnet src 172.16.0.0/12   # RFC1918 possible internal network

acl localnet src 192.168.0.0/16   # RFC1918 possible internal network

acl SSL_ports port 443

acl Safe_ports port 80      # http

acl Safe_ports port 21      # ftp

acl Safe_ports port 443      # https

acl Safe_ports port 70      # gopher

acl Safe_ports port 210      # wais

acl Safe_ports port 1025-65535   # unregistered ports

acl Safe_ports port 280      # http-mgmt

acl Safe_ports port 488      # gss-http

acl Safe_ports port 591      # filemaker

acl Safe_ports port 777      # multiling http

acl Safe_ports port 901      # SWAT

acl purge method PURGE

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access allow purge localhost

http_access deny purge

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localnet

http_access allow localhost

http_access deny all

icp_access allow localnet

icp_access deny all

htcp_access allow localnet

htcp_access deny all

http_port 192.168.0.10:3128 transparent

hierarchy_stoplist cgi-bin ?

cache_dir ufs /var/cache/squid 1024 16 256

maximum_object_size 25600 KB

access_log /var/log/squid/access.log squid

refresh_pattern ^ftp:      1440   20%   10080

refresh_pattern ^gopher:   1440   0%   1440

refresh_pattern (cgi-bin|\?)   0   0%   0

refresh_pattern .      0   20%   4320

icp_port 3130

forwarded_for off

coredump_dir /var/cache/squid
```

No sé que puede tener de diferente el servidor que estás usando para probar, pero si bajo ese archivo http://daigertech.com/handbrake/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz mi Squid no lo cachea.

Por otro lado, el mismo archivo, pero bajado desde otro servidor:

```
~ # wget http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

--2009-07-03 23:15:53--  http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

Resolving download.m0k.org... 88.191.20.206

Connecting to download.m0k.org|88.191.20.206|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 5364245 (5.1M) [application/x-gtar]

Saving to: `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.2'

100%[=====================================>] 5,364,245   27.5K/s   in 3m 15s  

2009-07-03 23:19:08 (26.9 KB/s) - `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.2' saved [5364245/5364245]

~ # wget http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

--2009-07-03 23:19:13--  http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

Resolving download.m0k.org... 88.191.20.206

Connecting to download.m0k.org|88.191.20.206|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 5364245 (5.1M) [application/x-gtar]

Saving to: `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.3'

100%[=====================================>] 5,364,245   11.2M/s   in 0.5s    

2009-07-03 23:19:13 (11.2 MB/s) - `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.3' saved [5364245/5364245]
```

Como ves, llega casi a los 12M/s que debería tener en la red de 100 mbps en la que está.

A ver si es eso... 

Salud!

----------

## Txema

```
wget http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

--2009-07-04 11:26:51--  http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

Resolviendo download.m0k.org... 88.191.20.206

Connecting to download.m0k.org|88.191.20.206|:80... conectado.

Petición HTTP enviada, esperando respuesta... 200 OK

Longitud: 5364245 (5,1M) [application/x-gtar]

Saving to: `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.11'

100%[=========================================================================================================================================>] 5.364.245   4,03M/s   in 1,3s

2009-07-04 11:26:53 (4,03 MB/s) - `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.11' saved [5364245/5364245]
```

Este es el máximo que he alcanzado, y durante el proceso squid supera el 90% de CPU, me parece que es un problema de CPU y HD poco potentes... el procesador es un Pentium(R) 4 CPU 1.60GHz y el HD es un SATA nuevecito pero conectado con un adaptador a un puerto IDE porque no quería comprar una placa nueva, sino usar lo que ya tenía.

Saludos.

P.D: voy a compilar el kernel modificando algunas cosas como el timer frequency

P.D.2: madre mía qué cambio, he quitado el escalador de frecuencias de intel y he dejado el propio de acpi, además he bajado Timer frequency a 300 Hz y Preemption Model lo he puesto en desktop ¿cómo tienes tú estos valores?

Bueno el resultado es este:

```
wget http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

--2009-07-04 13:20:36--  http://download.m0k.org/handbrake/releases/HandBrake-0.9.3-Ubuntu_CLI_i386.tgz

Resolviendo download.m0k.org... 88.191.20.206

Connecting to download.m0k.org|88.191.20.206|:80... conectado.

Petición HTTP enviada, esperando respuesta... 200 OK

Longitud: 5364245 (5,1M) [application/x-gtar]

Saving to: `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.1'

100%[=========================================================================================================================================>] 5.364.245   8,89M/s   in 0,6s

2009-07-04 13:20:36 (8,89 MB/s) - `HandBrake-0.9.3-Ubuntu_CLI_i386.tgz.1' saved [5364245/5364245]
```

Bastante mejor  :Smile: 

----------

## Inodoro_Pereyra

Este servidor de caché es un Semprom 2600+ socket 754 que corre a 1600Mhz también con 512Mb de ram. Para lo que hace siempre supuse que sobraría aunque ahora tengo mis serias dudas...

Bueno, no, acabo de probar bajando el mismo archivo ese handbrake_nosecuanto y el uso del procesador ni se mueve, se mantiene debajo del 5% que consumen otros servicios, de hecho al proceso de squid ni siquiera lo veo aparecer en la lista, en el "top 20" digamos, ordenando por uso de CPU.

El hecho de que tengas el disco Serial ATA conectado a una controladora PCI me ha dejado pensando, no será que no tiene DMA activado? Que te devuelve hdparm -tT /dev/Disco_donde_se_aloja_el_caché ??

Puede que (entre otras cosas) el problema venga por ese lado.

El disco en donde se aloja la caché es un SATA conectado a una controladora Promise Fasttrack 378 y como todo disco SATA común y silvestre:

```
# hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   732 MB in  2.00 seconds = 365.96 MB/sec

 Timing buffered disk reads:  172 MB in  3.00 seconds =  57.33 MB/sec
```

CPU Frequency scaling ni siquiera lo tengo habilitado. Que opción es esa de Timer freq Model?

Salud!

----------

## Txema

El disco no está en un puerto PCI sino IDE, aunque para el caso viene a ser parecido.

Un hdparm me devuelve el mismo resultado que otros discos IDE que he tenido en el mismo PC

```
hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   388 MB in  2.01 seconds = 193.51 MB/sec

 Timing buffered disk reads:   82 MB in  3.06 seconds =  26.82 MB/sec
```

Ahora se ha reducido muchísimo el consumo de CPU, el squid sigue dando picos pero de mucha menor intensidad y muy breves, si no te fijas ni se ven.

Las opciones son:

```

  ┌──────────────────────────────────────────── Processor type and features ──────────────────────────────────────

Preemption Model (Voluntary Kernel Preemption (Desktop))  --->

                                                      │ │          ( ) No Forced Preemption (Server)                     │ │

                                                      │ │          (X) Voluntary Kernel Preemption (Desktop)             │ │

                                                      │ │          ( ) Preemptible Kernel (Low-Latency Desktop)

Timer frequency (300 HZ)  --->

                                                      │ │                          ( ) 100 HZ                            │ │

                                                      │ │                          ( ) 250 HZ                            │ │

                                                      │ │                          (X) 300 HZ                            │ │

                                                      │ │                          ( ) 1000 HZ                           │ │

```

Saludos

----------

## Inodoro_Pereyra

EL resultado de hdparm en tu servidor muestra una tasa de transferencia muy escasa para un disco rígido IDE.

Del resultado deduzco que o bien es un disco muy viejo o está trabajando en modo ATA66 (o UDMA4).

Si es un disco muy viejo, es normal. Si el disco es medianamente actual puede que esté conectado al controlador IDE con una manguera de datos de 40 conductores en lugar de la de 80, lo que lo limitaría al modo udma4 y a tan pobre tasa de transferencia...

Por ejemplo, te muestro un disco IDE, de la pc desde donde escribo ya mismo, que si bien puede trabajar en udma6 se ve limitado a udma5 por el chipset de la placa  madre:

```
/dev/sda:

 Timing cached reads:   478 MB in  2.00 seconds = 238.89 MB/sec

 Timing buffered disk reads:  134 MB in  3.09 seconds =  43.42 MB/sec
```

```
/dev/sda:

 IO_support    =  0 (default) 

 HDIO_GET_DMA failed: Inappropriate ioctl for device

 Model=SAMSUNG, FwRev=TK100-24, SerialNo=S00JJ30X825821

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4

 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156368016

 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4 

 DMA modes:  mdma0 mdma1 mdma2 

 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode
```

Un disco IDE trabajando en udma6 llega tranquilamente a 50M/s de tasa de transferencia.

Por otro lado, he mirado el preemption model del servidor que corre squid y al igual que el tuyo está en modo Voluntary Kernel Preemption (Desktop)...

----------

## Txema

Efectivamente ahí está el problema

```
Capabilities:

        LBA, IORDY(can be disabled)

        Queue depth: 1

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Recommended acoustic management value: 254, current value: 0

        DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 udma6

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns
```

Por lo visto no llega ni a udma4, se queda en udma2. como con los otros discos me daba lo mismo lo dejé pasar, ahora me he fijado en las especificaciones de mi placa y sorpresa:

 *Quote:*   

> I/O Controller Hub (ICH2)
> 
> ICH2 I/O             Ultra ATA/66/100
> 
> Controller Hub       Ultra DMA/33

 

Me parece que el resultado era de esperar ¿no?  además, el conector SATA to IDE que me dieron es efectivamente un conector de 40 pines... así que me temo que hasta que no llegue a mis manos otro PC, esto va a ser lo mejor que tenga, que ya es mucho más que lo que tenía con el router normal   :Very Happy: 

Saludos.

----------

## Inodoro_Pereyra

 *Txema wrote:*   

> el conector SATA to IDE que me dieron es efectivamente un conector de 40 pines... 

 

Ojo que todos los conetores IDE tiene 40 pines, eh? EL asunto es que tenga 80 conductores, 80 hilos en total, digamos.

Cuando apareció el formato udma empezaron a haber problemas debido a que la alta frecuencia a la que trabaja el cable de datos (Que se traduce en alta tasa de transferencia) produce reflexión de señal sobre el conductor, a raiz de eso se ha agregado un segundo conductor "mallando" al que lleva los datos, que va conectado a tierra. Al chasis en definitiva.

Por cada hilo de datos, uno de mallado, 80 conductores para 40 pines.

Los discos rígidos y la bios del mother usualmente sensan el tipo de cable. Si el cable es de 40 conductores no habilitan ningún modo de transferencia mas allá de udma4 para evitar los problemas que acarrearía tan alta frecuencia.

Salud!

----------

