Closed zhang19523zhao closed 5 days ago
好的,我这边反馈一下
请问现在的并发是多少呀
请问现在的并发是多少呀
200
import base64
import datetime
import os
import urllib
import requests
from concurrent.futures import ThreadPoolExecutor, wait, ALL_COMPLETED
executor = ThreadPoolExecutor(max_workers=200)
def ocr(path):
start_time = datetime.datetime.now()
print("start", start_time)
url = "http://10.0.0.104:6006/ocr"
payload = {"image": get_file_content_as_base64(path)}
response = requests.post(url, json=payload)
print(response.status_code, datetime.datetime.now() - start_time)
def get_file_content_as_base64(path, urlencoded=False):
with open(path, "rb") as f:
content = base64.b64encode(f.read()).decode("utf8")
if urlencoded:
content = urllib.parse.quote_plus(content)
return content
if __name__ == '__main__':
path = "png"
tasks = []
start_time = datetime.datetime.now()
for file in os.listdir(path):
# ocr(os.path.join(path, file))
tasks.append(executor.submit(ocr, os.path.join(path, file)))
wait(tasks, return_when=ALL_COMPLETED)
print("finish duration={}", datetime.datetime.now() - start_time)
目前开源版PaddleX提供的服务化部署方案在服务的并发性方面并没有做太多优化。具体来说,为了保证正确性,服务接受的请求在模型推理步骤是串行处理的(使用线程池,加锁)。因此,即使实际的并发请求数达到200,GPU占用仍然可能不是很高。如果需要部署并发性较好的服务,可以考虑星河零代码产线的本地服务化部署方案。
对于CPU占用较高,推测可能和模型预处理、后处理需要使用CPU进行大量计算有关,可通过限制进程使用的CPU核数来减少资源消耗。
目前开源版PaddleX提供的服务化部署方案在服务的并发性方面并没有做太多优化。具体来说,为了保证正确性,服务接受的请求在模型推理步骤是串行处理的(使用线程池,加锁)。因此,即使实际的并发请求数达到200,GPU占用仍然可能不是很高。如果需要部署并发性较好的服务,可以考虑星河零代码产线的本地服务化部署方案。
对于CPU占用较高,推测可能和模型预处理、后处理需要使用CPU进行大量计算有关,可通过限制进程使用的CPU核数来减少资源消耗。
好的谢谢
环境 在autoDL租的显卡测试
启动命令
paddlex --serve --pipeline ./ocr.yaml --port 6006 --device gpu
配置文件 ocr.yaml
Global: pipeline_name: OCR Pipeline: text_det_model: PP-OCRv4_server_det #可修改为微调后模型的本地路径 text_rec_model: PP-OCRv4_server_rec #可修改为微调后模型的本地路径 text_rec_batch_size: 10 device: "gpu:0"
cpu占用很高,迸发测试多开几个paddlex应用用nginx代理显存提升不是很多卡在cpu处理