Bloggers recientes


[ Blog ]
[ Wiki ]
[ Slideshare ]
[ Twitter ]
[ YouTube ]
Cesar Capillas Mensajes: 178
Estrellas: 8
Fecha: 7/09/15
Gustavo Fernandez Mensajes: 79
Estrellas: 7
Fecha: 21/08/15



noBlogo - El blog de

Linux commands for network checking in Alfresco
Last day we wrote a little bit about basic commands to check disks in an Alfresco installation [4]. This post is inspired in some basic network recipes and tests for an Alfresco installation, usually in a three tier configuration composed by three boxes. For example:
  • A - Apache Frontend
  • B - Alfresco Server
  • C - Database Server 
First checking we do is to try simple pings between the boxes via ping -c command. A suitable network perfomance (for Alfresco) is getting roundtrips (rtt) smaller than 1 ms and a standard deviation less than 0.1 ms between Alfresco and Database Server. This test in fact, is part of Alfresco Environment Validation Tool (EVT) and it is part of Alfresco documentation.
From Computer B:
$ ping -c database-server
We usually need first to check some ports, for example via nc command [1] & [2], a very useful tool for checking ports, telnet usage, transfer files or partitions, and so on. For example from Apache Web server we may want to check if there are available 8009 and 8080 ports in Alfresco server for reverse proxy. It is clear that all ports mentioned must be available via local iptables (in the following example 8009 and 8080 in Alfresco Server).
From Computer A:
$ nc -v alfresco-server 8009
$ nc -v alfresco-server 8080
NOTE: You must check these ports in an Alfresco installation [3]
These ports are typical in any tomcat server. From your nagios / icinga box, you may want to monitor JMX in Alfresco. Then you need to enable JMX in Alfresco Server and configure JMX monitor port (monitor.rmi.service.port=50508) defined in
And from Nagios / Icinga Box:
$ nc -v alfresco-server 50508
A network perfomance can be achieved via a combination of nc and dd command. Last day, we used dd to test how fast our disks write. 
For example:
In Computer C (database server), we can open a socket in 12345 (this port must be opened via local iptables).
$ nc -vvlnp 12345 > /dev/null
In Computer B (application server):
$ dd if=/dev/zero bs=1M count=1K | nc -vvn database-server 12345
Connection to database-server 12345 port [tcp/*] succeeded!
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 9.11995 s, 118 MB/s
Another possibility, mentioned by Gustavo in this blog for doing this [5] and [6], is via iperf (we need iperf installed in both boxes) which uses 5001 as default port 
Then on Computer C (as server - needs 5001 port):
$ iperf -s -p 5001 
And on Computer B:
$ iperf -c <address of Computer C>
Client connecting to database, TCP port 5001
TCP window size: 16.0 KByte (default)
[  3] local alfresco port 37248 connected with database port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.04 GBytes    893 Mbits/sec
Linux commands to check network performance

Siguiendo un poco con el post de mi compañero Cesar , voy a poner una receta para comprobar la velocidad de transferencia entre equipos. En realidad para ello se uso el comando iperf, que se puede instalar en ubuntu, debian y centos/redhat con los gestores de paquetes de cada distro. Lo que hay que hacer es

  1. Levantar un socket de recpción en la maquina destino (iperf -s)
  2. Desde la máquina origen llamar al servicio que se ha inciado en el puerto 5001 (iperf -c IP_DE_LA_OTRA_MAQUINA)

El resultado será un pequeño informe, por pantalla de la velocidad de transferencia entre ambos equipos.

Sencillo pero muy útil...


Linux commands to check your disk performance
Yesterday I read in, NAS or SAN, that is the question, in fact a usual question for Alfresco Administrators:
In some part of the article, Toni says that Alfresco recommends a disk throughput greater than 200 MB/sec, so I decided to check some linux commands for measuring disk performance. This will impact for example in the normal work of Alfresco indexation and search (Lucene and SOLR seacrh subsystems). Also when importing data to Alfresco via Filesystem Bulk Module, CMIS/REST API custom processes, or even uploading data via CIFS, FTP or Webdav drives. Because sometimes the throughput results of a Bulk filesystem import are not good enough as expected, sometimes we have to think that something is rotten in the state of benchmark, and yes, that is the question!.
Usually this can is done with hdparam and dd commands. Below, I do some tests with my laptop with a quite recent SSD disk. So the results here obtained are quite good (take in consideration: local + SSD = fast). First one is hdparm:
cesar@erotes ~ $ sudo hdparm -tT /dev/sda
 Timing cached reads:   12326 MB in  2.00 seconds = 6165.99 MB/sec
 Timing buffered disk reads: 1426 MB in  3.00 seconds = 474.67 MB/sec
The important part is related to buffered disk reads. When we are measuring disk performance we usually talk about non cached reads (or writes). This command can be applied to IDE/SATA disks (LVM disks or iSCSI disks). The hdparm command does not work for CIFS or NFS. For testing NFS, CIFS you can use specific utilities or check dd. 
To check write performance, it is useful the dd command. Here again, it is important to check caches or deactivating them for testing. You can deactivate cache writing in a disk with the help of hdparm command too (for example for sda local sata disk something like sudo hdparm -W1 /dev/sda)
We can test streaming (for example 1 iteration of 1G): With write caching on, normally activated (if not you can apply sudo hdparm -W1 /dev/sda):
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile1 bs=1G count=1 oflag=direct
1+0 records read
1+0 records written
1073741824 bytes (1,1 GB) copied, 2,44595 s, 439 MB/s
If I deactivate write caching:
cesar@erotes ~ $ sudo hdparm -W0 /dev/sda
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
And I repeat the test:
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile2 bs=1G count=1 oflag=direct
1+0 records read
1+0 records written
1073741824 bytes (1,1 GB) copied, 6,9191 s, 155 MB/s
We see how a similar test without caches is quite worse. We can also test latency (for example with 1000 iterations of 512b) and activating write-cache again:
cesar@erotes ~ $ sudo hdparm -W1 /dev/sda
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile3 bs=512 count=1000 oflag=direct
1000+0 records read
1000+0 records written
512000 bytes (512 kB) copied, 0,0392862 s, 13,0 MB/s
Deactivating write-caching again:
cesar@erotes ~ $ sudo hdparm -W0 /dev/sda
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
cesar@erotes ~ $ dd if=/dev/zero of=/tmp/testfile4 bs=512 count=1000 oflag=direct
1000+0 registros leídos
1000+0 registros escritos
512000 bytes (512 kB) copiados, 1,63136 s, 314 kB/s
This last test hurts. Roughly speaking, this is the reason why your TV series in HD seems faster to copy than your huge icon galleries when you upload them to Alfresco.  
Sometimes you read, that dd needs to sync data to get "real" measurements, so the performance is in fact a little worse (this can be achieved with the oflag=sync and repeating the tests). The oflag modes are better explained in the second link below.
Some of the links I used for the article:
Limiting the number of cores for Alfresco Transformations
This is an Alfresco Tip taken from my test on Alfresco Honeycomb Edition (I will post some notes about this other day). The tip is related to limit the number of cores used by Alfresco transformation, preventing CPU throttling
In set:
where the original script is:
#! /bin/bash
# This file is to limit the number of cores used by Alfresco transformation
# and prevent cpu throttling. The script limits ImageMagick convert to use less resources.
# Check the number of available cpu:s with
# cat /proc/cpuinfo | grep processor | wc -l
# If you have more, change to -c 0,1 if you have 4, -c 0,1,2 if you have 6 and so on.
# Check man taskset for more info.
# Copyright 2013 Loftux AB, Peter Löfgren
# Distributed under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC BY-SA 3.0)
# -------
taskset -c 0 /usr/bin/convert $@
Empaquetando aplicaciones java para MACOS

A continuación voy a da algunas referencias que nos han ayudado en la automatización de la generacion de empaquetados para MACOS, de aplicaciones java. En empezamos a hacer nuestros primeros desarrollos multiplataforma allá por el año 2009 cuando desarrollamos, junto a otros miembros de la comunidad, la primera versión de sinadura. Después de 6 o 7 años el proceso de empaquetar aplicaciones para MACOS lo hemos ido mejorando mientras hacíamos proyectos con izenpe, lantik etc... Este mes he estado involucrado en el desarrollo de un cliente de firma que use lo que se conoce como firma por protocolo. Este cliente funcinará con MACOS y se distribuirá como un .dmg[0] con su .app para MACOS.

Para poder automatizar la generación de los instaladores para las distintas plataformas usamos estrategias diferentes para cada sistema operativo.

 * Linux (Izpack[1][2] y la generación de un .run[3])
 * Windows (Izpack y launch4j[4])
 * MACOS (JarBundle[5] y genisoimage[6])

En todos estos sabores de sistemas operativos y arquitecturas, automatizamos las generaciones usando ant o maven para que desde nuestra máquina de QA se puedan generar los empaquetados sin necesidad de disponer de maquinas específicas que generen los empaquetados para cada Sistema operativo.

A continuación mostramos unas imágenes de nuestra herramienta de integración continua desde la que podemos generar y publicar los instaladores de sus distintos sabores.

Para este proyecto también hemos hecho que los instaladores registren los protocolos necesarios para que la firma por protocolo funcione. En este caso para windows se usa el registro de windows, en linux se usa xdg[7] y en MACOS se usa el Info.plist[8] de la app


Mostrando el intervalo 1 - 5 de 297 resultados.
Resultados por página 5
de 60