From f64111a7e27fb6e7eabc4e597e96d1adbbccb954 Mon Sep 17 00:00:00 2001 From: Ubuntu Date: Sat, 4 Jan 2020 15:56:35 +0000 Subject: [PATCH] terminology clarification --- README.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 4d1be5f..e801882 100644 --- a/README.md +++ b/README.md @@ -4,8 +4,8 @@ An image proccessing service, for using [YOLOv3-object-detection-tutorial](https This stack presents two ways of running: -1. As a Flask app in the `processing` container which contains all the heavy processing dependencies. -2. As a Flask app in its own lighter `flask` container which passes the processing to the `processing` container via `rq` +1. As a Flask app in the `processor` container which contains all the heavy processing dependencies. +2. As a Flask app in its own lighter `flask` container which passes the processing to the `processor` container via `rq` Initially I implemented mode (2), then I realised performance was very fast with mode (1): `~1.6` seconds per image conversion on a CPU. However in mode (1) when a request comes in a UWSGI worker which handles the request will block. This is a consideration when scaling, as if you want to handle bulk ingress of images, a CPU core is needed per request, and unavailable while the processing happens. With mode (2) many images can be uploaded quickly, then processing capacity scaled for demand. With the latter mode the endpoint returns a url for the image. Until processing is complete it currently just returns a string 'processing'. @@ -17,7 +17,7 @@ Clone repo. git clone https://github.com/vulcan25/image_processor cd image_processor -Grab the weights. You may have your own. I used the file from `pjreddie.com/media/files/yolov3.weights`. Put this file in the subdirectory `processor/`. When the `processing` container builds, it copies this in as it then runs the `convert.py` script on the models. With this approach the converted models then become part of the docker image. +Grab the weights. You may have your own. I used the file from `pjreddie.com/media/files/yolov3.weights`. Put this file in the subdirectory `processor/`. When the `processor` container builds, it copies this in as it then runs the `convert.py` script on the models. With this approach the converted models then become part of the docker image. Build the containers: @@ -25,7 +25,7 @@ Build the containers: ## mode (1)... -Launch with mode (1) which will expose a Flask app in the `processing` service on `http://localhost:5001`. This means the Flask app exists on the same container as the image processing dependencies. +Launch with mode (1) which will expose a Flask app in the `processor` service on `http://localhost:5001`. This means the Flask app exists on the same container as the image processing dependencies. docker-compose up @@ -75,14 +75,14 @@ Viewing this URL will return the string "processing" unless the job is done, at # Bug List -- `processing` container image too large at `~3.2GB` +- `processor` container image too large at `~3.2GB` - `flask/app.py` uses container fs storage (`/tmp`): probably should find a way around this. Maybe S3 via boto3, or similar. - `processor/app.py` doesn't support any storage; everything is handled in memory. Code could be added to make this store in some manner. - `app.py` and `index.html` are similar in the processing and flask service respectivly. Find a better way to make these more modular. # Timing snippet -The following can be run in the processing container: +The following can be run in the `processor` container: You can get into a running container with: `docker exec -it image_processor_processor_1 /bin/bash`