Udostępnianie obiektu między pracownikami Gunicorn lub utrzymywanie obiektu wewnątrz pracownika

Question

Piszę aplikację WSGI przy użyciu stosu Nginx/Gunicorn/Bottle, który akceptuje żądanie GET, zwraca prostą odpowiedź, a następnie zapisuje wiadomość do RabbitMQ . Gdybym był uruchomiony przez prostą butelkę, używałbym połączenia RabbitMQ za każdym razem, gdy aplikacja otrzyma GET. Jednak w Gunicorn wygląda na to, że pracownicy za każdym razem niszczą i odtwarzają połączenie MQ. Zastanawiałem się, czy istnieje dobry sposób na ponowne wykorzystanie tego połączenia.

Więcej szczegółowych informacji:

##This is my bottle app 
from bottle import blahblahblah 
import bottle 
from mqconnector import MQConnector 

mqc = MQConnector(ip, exchange) 

@route('/') 
def index(): 
    try: 
    mqc 
    except NameError: 
    mqc = MQConnector(ip, exchange) 

    mqc.publish('whatever message') 
    return 'ok' 

if __name__ == '__main__': 
    run(host='blah', port=808) 
app = bottle.default_app() 

Answer 1

Dobra, to zajęło mi trochę czasu, aby uporządkować. Co się działo, za każdym razem, gdy pojawiała się nowa prośba, Gunicorn uruchomił moją metodę index() i jako taki stworzył nową instancję MQConnector.

Poprawka dotyczyła refaktora MQConnector w taki sposób, że zamiast być klasą, była to tylko garść metod i zmiennych. W ten sposób każdy pracownik odwoływał się za każdym razem do ten sam MQConnector, zamiast tworzyć nowe wystąpienie MQConnector. Na koniec przekazałem funkcję MQConnectora publish().

#Bottle app 
from blah import blahblah 
import MQConnector 

@route('/') 
def index(): 
    blahblah(foo, bar, baz, MQConnector.publish) 

i

#MQConnector 
import pika 
mq_ip = "blah" 
exhange_name="blahblah" 

connection=pika.BlockingConnection(.... 
... 

def publish(message, r_key): 
    ... 

Wyniki: telefon, że wykorzystywane do podejmowania 800ms teraz trwa 4ms. Kiedyś max na 80 połączeń na sekundę przez 90 pracowników Gunicorn, a teraz mam max około 700 połączeń na sekundę przez 5 pracowników Gunicorn.