Я занимаюсь разработкой flask приложения. Это простое приложение с одной конечной точкой, индекс (/) на данный момент. В моих проектах __init__.py
файл, прежде чем что-либо импортировать, я обезьяна исправляю все библиотеки с monkey.patch_all()
. Вот как выглядит мой __init__.py
:
# --- imports begin
from gevent import monkey
monkey.patch_all()
from flask.json import JSONEncoder
import os
import logging
from flask import Flask
from mixpanel import Mixpanel
from logging.handlers import TimedRotatingFileHandler
from flask_log_request_id import RequestID, RequestIDLogFilter
from foree.helpers.py23_compatibility import TEXT_ENCODING
# --- imports end
# application objects
app = Flask(__name__)
....
Маршрут индекса имеет один вызов БД для коллекции, которая проиндексирована с помощью ключа phone_number
, и мой запрос выглядит так: {phone_number: 'XYZ'}
. Индексный маршрут выглядит следующим образом:
@app.route('/')
def index():
_ = user_by_phone_number('XYZ')
import socket
return jsonify(message='Hello!',
min_version=MIN_VERSION,
max_version=MAX_VERSION,
app_version=SERVER_VERSION,
config_checksum=CONF_CHECKSUM,
environment=DEPLOYMENT,
host=socket.gethostname(),
time=str(datetime.datetime.now()))
И функция user_by_phone_number
выглядит следующим образом:
def user_by_phone_number(phone_number):
db['fpi_user'].find_one({'phone_number': phone_number})
У меня 4-ядерный процессор с оперативной памятью 8 Гб. Сервер порождается:
gunicorn --bind 127.0.0.1:18000 --access-logfile gunicorn-access.log --access-logformat '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s Time: %(T)s' -w 9 --worker-class gevent --worker-connections 1000 foree:app --log-level debug
I, а затем go для генерации некоторой нагрузки на этом сервере с использованием locust
. Саранча работает в распределенном режиме с 3 подчиненными и мастером (2500 одновременных пользователей с частотой штриховки 200) через locust --no-web -c 2500 -r 200 -H https://myhost.com/ -t 2m --master --expect-slaves=3
. Результат теста очень низкий TPS. Наблюдая mongostat
, я получаю количество ~ 1K операций / сек c на моем дополнительном устройстве (набор реплик).
С другой стороны, я попытался протестировать MongoDB с YCSB
и неожиданно результаты были несколько хорошими. Среднее количество операций / сек c на вторичном уровне составляет около 21K. Это означает, что MongoDB используется не полностью (в случае моего сервера приложений). И да, моя база данных и сервер приложений находятся в одной сети с пингом менее 1ms
, поэтому задержка не может быть проблемой здесь.
Вот как я тестирую с YCSB:
./bin/ycsb run mongodb -s -P workloads/workloadc -threads 20 -p mongodb.url="mongodb://username:pass@<list-of-dbs>/DB?replicaSet=rs0&retryWrites=true&readPreference=secondary&localThresholdMS=30&maxPoolSize=5000" -p operationcount=10000000
Я также попытался добавить New Reli c в свой код, чтобы выяснить причину проблемы, и он также жалуется на функцию PyMon go find_one
, которую я вызываю на индексном маршруте. Вот снимок:
Я пытался понять это в течение 3-4 дней без какой-либо удачи. Любые выводы о том, что здесь может быть не так, будут высоко оценены. Спасибо.