Tracer la latence avec NGINX

Extracted from nginx blog, article from Rick Nelson · January 7, 2016


Using the NGINX Built-In Timing Variables

NGINX provides a number of built-in timing variables that you can include in log entries. All are measured in seconds with millisecond resolution.

  • $request_time – Full request time, starting when NGINX reads the first byte from the client and ending when NGINX sends the last byte of the response body
  • $upstream_connect_time – Time spent establishing a connection with an upstream server
  • $upstream_header_time – Time between establishing a connection to an upstream server and receiving the first byte of the response header
  • $upstream_response_time – Time between establishing a connection to an upstream server and receiving the last byte of the response body

Here is a sample log format called apm that includes these four NGINX timing variables along with some other useful information:

log_format apm '"$time_local" client=$remote_addr '
               'method=$request_method request="$request" '
               'request_length=$request_length '
               'status=$status bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               'user_agent="$http_user_agent" '
               'upstream_addr=$upstream_addr '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time';

 

Using Application-Defined Timing Values

To drill down, we capture timings in the application itself and include them as response headers, which NGINX then captures in its access log. How granular you want to get is up to you.

To continue with our example, we have the application return the following response headers which record processing time for the indicated internal operations:

  • db_read_time – Database lookup
  • db_write_time – Database write
  • analysis_time – Data analysis
  • other_time – All other types of processing

NGINX captures the timing values from the response headers by creating corresponding variables, which it names by prepending the string $upstream_http_ to the header name (for example, $upstream_http_db_read_time corresponds to db_read_time). You can then include the variables in log entries just like standard NGINX variables.

Here is the previous sample log format extended to include the application header values:

log_format apm 'timestamp="$time_local" client=$remote_addr '
               'request="$request" request_length=$request_length '
               'bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               'user_agent="$http_user_agent" '
               'upstream_addr=$upstream_addr '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time '
               'app_db_read_time=$upstream_http_db_read_time '
               'app_db_write_time=$upstream_http_db_write_time '
               'app_analysis_time=$upstream_http_analysis_time '
               'app_other_time=$upstream_http_other_time ';

Format d’image avec compression lossless

Sur le papier le meilleur format d’image avec compression lossless semble être FLIF:

http://flif.info/

FLIF a aussi l’avantage d’être libre de droit (dixit leur site).

Le format BPG est un peu moins bon au vue des comparatifs :

http://cloudinary.com/blog/flif_the_new_lossless_image_format_that_outperforms_png_webp_and_bpg

Il reste une bonne option bien que susceptible de tomber sous licence dans certains pays à cause du HEVC :

https://bellard.org/bpg/

 

 

Drawing ASCII dans le message de bienvenue d’une debian

Le fichier /etc/motd est bien pratique pour customiser le message de bienvenue et éviter de se mélanger les pinceaux lorsque l’on administre un petit lot de serveur.

L’outil Figlet permet de faire un drawing ASCII en une ligne de commande :

$ figlet Mon-Serveur

l’option -f permet de choisir le style de la police utilisée. Ajoutez les polices « contrib » si vous voulez avoir du choix.

Résolution des liens symboliques avec Xdebug

Dans une configuration Xdebug + IDE (eclipse, phpStorm…) si vous commencez à avoir des liens symboliques, l’IDE ou xdebug commence à perdre les pédales sur la résolution des chemins ce qui fait que les breakpoints de l’IDE ne sont plus détectés.

Voici une technique pour continuer à utiliser le principe de lien symbolique et à utiliser xdebug :

  • vérifier que xdebug fonctionne bien : activer l’arret sur la première ligne de code dans l’IDE
  • vérifier que les mapping serveur sont corrects (dans la config du serveur dans l’IDE)
  • supprimer le lien symbolique et créer un bind (on perd en lisibilité mais ça réalise la même fonction à un niveau un peu plus bas).

Imaginons que le lien symbolique était dans le répertoire /opt/mon_projet/trunk/src/ avec cette résolution:

web -> /opt/mon_projet/trunk/skins/skin_1/web/

Avec un bind il suffit de faire ceci:

 cd /opt/mon_projet/trunk/src/
 mkdir web
 mount -B /opt/mon_projet/trunk/skins/skin_1/web/ web

Un tutoriel sur Gulp pour comprendre les dépendances, l’utilisation de tâches asynchrones ou synchrones

J’ai pris de le temps de faire ce tutoriel car je vois trop souvent des incompréhensions sur ces notions de tâches synchrones et asynchrones. En complément je rappelle le principe de dépendances dans gulp. Les dépendances ne sont pas ordonnées, seul la fin de la tâche déclenche l’exécution de la suivante, il faut donc s’assurer que les fins tâches sont déclenchées seulement lorsqu’elles sont effectivement terminés. Ceci amène à la notion de barrière et de promesses (je n’ai pas détaillé les promesses ici, les docs ne manquent pas sur ce sujet).

Au niveau dépendances

Les logs de ‘un’ se mixe avec ‘trois’ en asynchrone (c’est que l’on cherche) mais ‘deux’ ne se lance bien qu’après la fin de ‘trois’.

Mise en œuvre d’une barrière pour gérer correctement les fins de tâches asynchronesIl n’y a pas besoin de mettre en place de section critique en js, chaque fonction possède son propre contexte, donc la barrière qui gère la fin de l’ensemble des process est plutôt simple à mettre en œuvre.

Au niveau perf

En asynchrone je boucle la tâche ‘quatre’ en 3,6 secondes alors qu’en synchrone elle se boucle en 4,4 secondes. Cela commence à faire beaucoup sur si peu d’itérations.

Le code

J’ai commenté en anglais histoire de partager un peu.

var child_process = require('child_process');


function execScriptAsync(script, cb) {
//	var _script=script;
//	var _cb=cb;
    //this function is triggered on script is completed
	function onCompleted(error, stdout, stderr){
		if (error) {
        	console.log("Error on script: "+script+ " error = "+error);
        } else {
            console.log("Execution completed on : "+script);
		    console.log("   stdout: "+stdout);
	        if (stderr) console.log("   stderr: "+stderr);
		}
	    if (cb) {
	        cb(error);
	    }
	} 
	console.log("Executing script : "+script);
	child_process.exec(script, onCompleted);
};

var runnerAsync = function (name, iteration, cb) {
    var i=0;
    var j=iteration;
    // this function is used as a barrier, once all process are completed, trigger the callback so the task will be ended properly.
    var wait = function() {
        j--;
        console.log("   Remaining '"+name+"' process="+j);
        if (j==0) {
            // do not forget to call the callback, gulp is using this to trigger the task ended
            cb();
        }
    }
    for (i=0; i<iteration; i++) {
        execScriptAsync('echo '+name, wait);
        //we are reaching this code even if the echo command is not ended, so we can have several echo called simultaneously
        // the number of echo in parallel depends on how many process can be started simultaneously on the box
    }
    // do not call the callback here otherwise you will have the task completed while 'echo' cmd are still running
};

var runnerSync = function (name, iteration, cb) {
    for (var i=0; i<iteration; i++) {
        var echo = child_process.spawnSync('echo', [name], {shell: true});
        //we are reaching this code only once the echo command is ended
        if (echo && echo.stdout) {
            console.log('stdout: '+echo.stdout);
        }
    }
    cb();
};

// switch from runnerSync to runnerAsync this to see the difference between synchronous and asynchronous
var runner=runnerAsync; // runnerAsync;

gulp.task('one', function(cb) {
    runner('one', 100, cb);
});

gulp.task('two', ['three'],function(cb) {
    runner('two', 100, cb);
});

gulp.task('three', function(cb) {
    runner('three', 100, cb);
});

var Q = require('q');
// keep start time of gulp
var startTime=new Date();
// here we can see dependencies behavior, 'two' should be triggered before 'three', but 'two' depends on 'three' so 'three' comes first.
gulp.task('four', ['one', 'two', 'three'], function() {
    //in this task, I'm using a promise which is a better way to handle async process response
    //(with gulp it is not simple to add functional rules between tasks, everything rely on dependencies)
    var deferred = Q.defer();
    var cb=function(data){
        var end=new Date();
        var elapsed=end.getTime() - startTime.getTime();
        console.log("Total time elapsed="+elapsed+' ms');
        // resolve the task 'four'
        deferred.resolve();
    }
    // start processes
    runner('four', 100, cb);
    // return the promise so gulp will be able to process the task completion properly
    return deferred.promise;
});


Problème GTK sur Eclipse-Neon2 avec une Lubuntu

Version ubuntu:

Distributor ID:	Ubuntu
Description:	Ubuntu 16.10
Release:	16.10
Codename:	yakkety

Cas de la perte des icônes de base et message d’erreur au lancement

Si les messages sont du type:

(Eclipse:14401): Gtk-WARNING **: Theme parsing error: gtk-lubuntu.css:309:15: The 'icon-shadow' property has been renamed to '-gtk-icon-shadow'
(Eclipse:14401): GLib-CRITICAL **: g_base64_encode_step: assertion 'in != NULL' failed

Créer le script sh suivant :

#!/bin/bash
export GDK_BACKEND=x11
export SWT_GTK3=0
ECLIPSE_PATH=`dirname "$(readlink -f "$0")"`
echo $ECLIPSE_PATH
$ECLIPSE_PATH/eclipse

puis lancer eclipse via ce script.

Cas d’une exception

Si eclipse plante complètement avec ce message :

Exception in thread "DLTK indexing" java.lang.ExceptionInInitializerError
	at org.eclipse.dltk.internal.core.index.lucene.LuceneIndexer.getDocuments(LuceneIndexer.java:104)
	at org.eclipse.dltk.internal.core.index2.AbstractIndexRequest.analyzeSourceModuleChanges(AbstractIndexRequest.java:124)
	at org.eclipse.dltk.internal.core.index2.SourceModulesRequest.run(SourceModulesRequest.java:64)
	at org.eclipse.dltk.core.search.indexing.AbstractJob.execute(AbstractJob.java:80)
	at org.eclipse.dltk.internal.core.search.processing.JobManager.run(JobManager.java:482)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
	at org.eclipse.dltk.internal.core.index.lucene.LuceneManager.<init>(LuceneManager.java:212)
	at org.eclipse.dltk.internal.core.index.lucene.LuceneManager.<clinit>(LuceneManager.java:74)
	... 6 more

Dans ce cas il faut supprimer le workspace et le recréer.

Problème de clavier avec Synergy entre un serveur window et un client Linux.

Si vous avez un problème de mauvais mapping de votre clavier sur le client Linux, vous pouvez essayer de forcer le mapping du client linux avec cette commande (il faut que le client soit connecté) :

Depuis une console sur le client linux:

 setxkbmap fr

nb: il y a aussi une autre façon de faire via le fichier de conf du serveur mais il faut que je remette la main dessus.

 

Multi-écran et raccourci openbox sur Lxde

Un petit mémo pour définir des raccourcis clavier sur LXDE afin de basculer d’une config multi-écran à une autre.

Pré-requis:

Installation de arandr pour créer les config xrandr (ca evite de se cogner la doc xrandr et l’ecriture des commandes xrandr)

 sudo aptitude install arandr

Lien vers xrandr pour approfondir

Définition et sauvegarde des layout d’écran

Créez les scripts xrandr avec arandr. Pour cela définissez l’organisation des écrans et faites « enregistrer sous », cela sauvegarde un script xrandr que l’on pourra executer via le raccourci.

Pour l’exemple je les ai stocké dans ~/.screenlayout/.

Définition des touches de raccourci

Editez le fichier .config/openbox/lxde-rc.xml

ajoutez par exemple :

   <keybind key="W-C-Up">
     <action name="Execute">
       <command>~/.screenlayout/vga_top_edp_bottom.sh</command>
     </action>
   </keybind>
   <keybind key="W-C-Down">
     <action name="Execute">
       <command>~/.screenlayout/edp_only.sh</command>
     </action>
   </keybind>

ca permet de lancer une config dual-screen (vga+edp) avec les touches CTRL+WIN+up et de revenir a l’ecran EDP seul avec CTRL+WIN+down

plus d’info sur les config openbox ici

Inspection de variables javascript

 

Voici un bout de code bien pratique pour inspecter vos variables javascript:

function listprop(o){
                 var objectToInspect;
                 var result =' [];

                 for(objectToInspect = o; objectToInspect !== <span' style=''color:#000080;font-weight:bold;''>null; objectToInspect = Object.getPrototypeOf(objectToInspect)){
                    result = result.concat'('Object.getOwnPropertyNames(objectToInspect));
                 }
                 $log.debug(''inspector=''<'/'span>+result);
                 return result;
}

le $log est de l’angular. un console.log peu’t’ faire l’affaire. lancez listprop(ma_varaible) et le tour est joué.

Notes on how to generate a DDPI of your album (using SOX and cue2ddp)

What is written on an AUDIO cd

The audio data is a basic row of bits, the trick is to tell the reader where to put the head to find the correct track. it is done with the cuesheet, it describes where are the tracks and eventually add CD-TEXT information.

You can find good information in the man page of cdrdao and cue2ddp tools on linux/mac and in the links below.

DDP step by step…

1: convert each track to raw file

So basically, once you have your .wav files, you just have to encode them in raw format with the following characteristics:

  • 44100 Hz
  • 16 bits signed integer
  • 2 channels
  • little endian (FYI: cdrdao is using big endian so you should switch to big endian if you want to burn your cd with your home tool. Industrial tools use little endian… make it simple they said…)

sox is your friend to do that.

I added normalization, dithering and stats to sox command. Stats is usefull to see if you have peaks or gain issues

#!/bin/bash


SOURCE=$1
cd $SOURCE

mkdir "raw"

WAV_FILES=`ls *.wav`

for WAV in $WAV_FILES; do
	FILENAME=`basename $WAV`
	echo "File: $WAV"
	sox $WAV -e signed-integer -b 16 -r 44100 -c 2 raw/$FILENAME.raw remix 1 1 gain -hn -3 gain -h dither stats
done

2: Concatenate all raw files in one single raw file

Once you have the raw files, you can put them all together in a single raw file, using cat for instance:

#!/bin/bash

BIN="$1.dat"
SOURCE=$2
cd "$SOURCE/raw"
RAW_FILES=`ls *.raw`

for RAW in $RAW_FILES; do
  FILENAME=`basename $RAW`
  echo "$RAW >>"
  cat $RAW >> $BIN
done

3: Generate the ddpi

The ddpi uses a plain text to generate the ddpi files. this file is identified as the cuesheet, it describes where is the raw file, what is the type of the raw file and where are the tracks and the index of each track. You should ook at the links below to see how to write a cuesheet file. Once you have the cuesheet file, you can generate the ddpi :

cue2ddp -ct -m My_Ref_1234 cuesheet.cdt ddp

Notes: -ct will generate cdtext information based on the cuesheet file. -m is the reference of your album, cuesheet.cdt is your cuesheet file. ddp is the target folder. This folder must be empty.

Links

Notes on creating cuesheet

Cuesheet syntax on wikipedia

Cuesheet syntax

SOX documentation