elMeu blog

[APDN] Impacte de l’arquitectura del node

Si recordeu algun dels meus últims posts sobre el meu projecte final de carrera, recordareu que us havia parlat de APDN, App Python Distributed Network. Doncs bé si tot va bé d'aquí a tres de setmanes presentaré davant del tribunal el projecte de forma definitiva. Finalment ha arribat el moment de començar a fer les proves de rendiment.

APDN és un middleware i com a tal s'interposa com una capa transparent entre el l'usuari i els nodes on s'executen tasques en segon pla. A cada node s'utilitza un programa anomenat apdnn, aquest s'encarrega d'executar les instàncies python, de seguir-les i finalment tancar-les.

El programa del node utilitza un model preforking per a realitzar el llançament de tasques, i utilitza un conjunt d'estructures de dades, un seguit de pipes i altres mecanismes IPC per a comunicar-se amb processos en espais d'adreces diferents.

Avui he he mesurat l'impacte de la infraestructura en el node. Aquesta tasca intenta mesurar quin overhead, si n'hi ha, provoca la pròpia infraestructura de programari de apdnn sobre el procés python. Normalment estructures, mecanismes de sincronització o altres com els comentats que formen part de apdnn poden provocar una penalització de CPU.

Un cop superats certs problemes amb el model d'atenció de peticions de xarxa sobre el servidor*, he pogut fer les proves que m'interessaven. Cal dir que ja m'esperava un impacte relativament baix, el propi programari apdnn no és molt intrusiu pels processos en segon pla un cop aquests s'estan executant.

En la prova que he fet he intentat demostrar que els processos python en un entorn amb APDN activat no tenen una penalització d'ús de la CPU versus un entorn no APDN. El resultat dels experiments l'he pogut reflectir amb el següent gràfic.

Aquest gràfic mostra quin és el nombre mig de claus md5 generades en un temps determinat per un conjunt de processos que incrementen de forma quadràtica. Lògicament si anem augmentant el nombre de processos aquests rivalitzen per la CPU i el nombre de claus md5 cau estrepitosament. Es interessant veure com l'arquitectura APDN no penalitza el procés batch amb menys CPU.

EL programa APDN per a fer aquesta demo es diu md5challenge, i té la següent pinta :

 
#!/usr/bin/python
#
# Example of app python code for app envelope
# Pau Freixes, pfreixes@milnou.net
# 2008-05-23
 
import signal
import md5
 
_nrdigest = 0
_const_b = 20
_f = None
_signal = False
 
def handler_alrm(signum, frame):
    global _signal
    global _nrdigest
    global _f
 
    _signal = True
 
def try_me():
    global _nrdigest
    global _f
    global _signal
 
    _f = open("/dev/urandom","r")
    while _signal is not True:
        buff = _f.read(_const_b)
        md5.md5(buff).hexdigest()
        _nrdigest = _nrdigest + 1
 
    if _f is not None :
        _f.close()
 
# Define entry point with one input variable
# req is a instance of Request object, usefull members of this object are:
# req.input is a dictionary with input.xml variables
# req.constants is a dictionary with constants defined into signature.xml
# req.output is void dictionary for full with output variables
# req.config is a dictionary with config values take from namespace
# req.apdn_pid is a pid of aplication
 
def main( req ):
    global _nrdigest
 
    signal.signal(signal.SIGALRM, handler_alrm)
    signal.alarm(req.input['time'])
 
    try_me()
 
    req.output['count'] = _nrdigest
 
    return req.OK
 
if __name__ == "__main__":
 
    # test code
    class test_req:
        pass
 
    req = test_req()
    req.input = { 'time' : 10 }
    req.output = { 'ret' : 0, 'count' : 0 }
    req.OK = 1
 
    main(req)
 
    print "Reached %d digests" % req.output['count']
 

Com podeu veure està preparat per córrer en standalone o bé sobre l'arquitectura APDN. Si ho fa en standalone un petit truc de python ens permet recrear un objecte del tipus Request i assignar-li en temps real els diccionaris necessaris perquè funcioni l'aplicació. En un entorn APDN la funció main ja rep de forma automàtica l'objecte Request. Aquest model d'execució és molt semplant al de mod_python.

*El model de xarxa ha canviat de working threads a un mix de working threads + dinamic temp threads. També s'ha afegit un model de cues per atenció de paquets de xarxa que fa el servidor una mica més equitatiu i evita el starvation de clients sobre nodes.