# flask-chatterbot

**Repository Path**: unlp/flask-chatterbot

## Basic Information

- **Project Name**: flask-chatterbot
- **Description**: chatterbot server with flask server
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-08-02
- **Last Updated**: 2021-08-02

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# [flask-chatterbot](https://github.com/chamkank/flask-chatterbot)

该项目是 [ChatterBot](https://github.com/gunthercox/ChatterBot) 项目的web 服务封装，直接使用 `` 即可开启服务

- 本地启动服务

```
python app.py

# app.py 文件中修改服务其地址

app.run(host='0.0.0.0')

# 在 `flask` 命令中修改

flask run --host=0.0.0.0

# 用 `gunicorn` 启动服务

gunicorn -w 2 -b :4000 app:app

# `gunicorn` 使用说明如下：
# -b BIND, --bind=BIND
# 设定服务需要绑定的端口。建议使用HOST:PORT。
# -w WORKERS, --workers=WORKERS
# 设置工作进程数。建议服务器每一个核心可以设置2-4个。
# -D,--daemon
# 后台进程方式运行gunicorn进程
# -k WORKERCLASS,--worker-class=WORKERCLASS
# 选定异步工作方式使用的模块。工作进程类型，包括sync（默认）,eventlet,gevent,tornado,gthread,gaiohttp
# --backlog INT
# 最大挂起的连接数
# --log-level LEVEL
# 日志输出等级
# --access-logfile FILE
# 访问日志输出文件
# --error-logfile FILE
# 错误日志输出文件
# app:app中，第一个app为文件名称即 app.py，第二个app为生成的flask项目实例即文件中包含的变量 app
# -c CONFIG, --config=CONFIG
# 设定配置文件。
# gunicorn配置文件是一个python文件，因此可以实现更复杂的逻辑，如下 (gunicorn.conf.py)：

import logging
import logging.handlers
from logging.handlers import WatchedFileHandler
import os
import multiprocessing
bind = '127.0.0.1:8000'      #绑定ip和端口号
backlog = 512                #监听队列
chdir = '/srv/applications'  #gunicorn要切换到的目的工作目录
timeout = 30      #超时
worker_class = 'gevent' #使用gevent模式，还可以使用sync 模式，默认的是sync模式

workers = multiprocessing.cpu_count() * 2 + 1    #进程数
threads = 2 #指定每个进程开启的线程数
loglevel = 'info' #日志级别，这个日志级别指的是错误日志的级别，而访问日志的级别无法设置
access_log_format = '%(t)s %(p)s %(h)s "%(r)s" %(s)s %(L)s %(b)s %(f)s" "%(a)s"'    #设置gunicorn访问日志格式，错误日志无法设置

"""
其每个选项的含义如下：
h          remote address
l          '-'
u          currently '-', may be user name in future releases
t          date of the request
r          status line (e.g. ``GET / HTTP/1.1``)
s          status
b          response length or '-'
f          referer
a          user agent
T          request time in seconds
D          request time in microseconds
L          request time in decimal seconds
p          process ID
"""
accesslog = "./log/gunicorn_access.log"      #访问日志文件
errorlog = "./log/gunicorn_error.log"        #错误日志文件

# 此时可以使用如下命令即可配置：
gunicorn -c gunicorn.conf.py app:app
```

`注` 
```
服务器和客户端的通信，我们简略的分为三个部分：request，request handling，和response，
即客户端向服务器发起请求，服务器端响应并处理请求，和将请求结果返回客户端，这三个过程。

通常，request handling这部分即服务端的计算，拼的是服务器的性能，处理是比较高效和稳定的，
而request和response部分，影响因素比较多，如果这三个过程放到同一个进程中同步处理，
如果request和response部分耗时比较多，会使计算资源被占据并无法及时释放，
导致计算资源无法有效利用，降低服务器的处理能力。

Gunicorn 是一个pre-forking的软件，这类软件对低延迟的通信，如负载均衡或服务间的互相通信，是非常有效的。
但pre-forking系统的不足是，每个通信都会独占一个进程，当向服务器发出的请求多于服务器可用的进程时，
由于服务器端没有更多进程响应新的请求，其响应效率会降低。

对于Web网站或服务而言，由于request和response延时是不可控的，我们需要在考虑处理高延迟客户端请求的情况。
这些请求会占据服务器端的进程。当慢客户端直接与服务通信时，由于慢客户端请求会占据进程，
可用于处理新请求的进程就会减少，如果有很多慢客户端请求把所有进程都占据后，新的请求只能等待有进程被释放掉后，
得到响应。另外，如果应用希望有更高的并发，服务器与客户端的通信要更高效，异步的通信会比同步的通信更有效。

Nginx这类异步的服务器软件擅长用很少的内存和cpu开销来处理大量的请求。由于他们擅长于同时处理大量客户端请求，
所以慢客户端请求对他们影响不大。就Nginx而言，现在一般的服务器硬件条件下，同时处理上万个请求都不在话下。

所以把Nginx挡在pre-forking服务前面处理请求是一种很好的选择。Nginx能够异步、高并发的响应客户端request
（慢客户端请求对Nginx影响不大），Nginx一旦接收到的请求后立刻转给Gunicorn服务处理，
处理结果再由Nginx以response的形式发回给客户端。这样，整个服务端和客户端的通信，就由原来仅通过Gunicorn的同步通信，
变成了基于Nginx和Gunicorn的异步通信，通信效率和并发能力得到大大提升。
```

- docker 启动

```
# MAINTAINER        Gevin <flyhigher139@gmail.com>
# DOCKER-VERSION    18.03.0-ce, build 0520e24FROM python:3.6.5-alpine3.7
LABEL maintainer="flyhigher139@gmail.com"

RUN mkdir -p /usr/src/app  && \
    mkdir -p /var/log/gunicorn

WORKDIR /usr/src/app
COPY requirements.txt /usr/src/app/requirements.txt

# 使用 gunicorn 来启动 flask 服务
RUN pip install --no-cache-dir gunicorn && \
    pip install --no-cache-dir -r /usr/src/app/requirements.txt

COPY . /usr/src/app

ENV PORT 8000
EXPOSE 8000 5000

CMD ["/usr/local/bin/gunicorn", "-w", "2", "-b", ":8000", "manage:app"]
```

#### A web implementation of [ChatterBot](https://github.com/gunthercox/ChatterBot) using Flask.

## Local Setup:
 1. Ensure that Python, Flask, SQLAlchemy, and ChatterBot are installed (either manually, or run `pip install -r requirements.txt`).
 2. Run *app.py* with `python app.py`.
 3. The demo will be live at [http://localhost:5000/](http://localhost:5000/)

## How do I deploy this to a web server?
If you do not have a dedicated server, I highly recommend using [PythonAnywhere](https://www.pythonanywhere.com/), [AWS](https://aws.amazon.com/getting-started/projects/deploy-python-application/) or [Heroku](https://devcenter.heroku.com/articles/getting-started-with-python#introduction) to host your application.

### Deploying on Heroku
If you are deploying on Heroku, you will have to change the database adapter from `chatterbot.storage.SQLStorageAdapter` to `chatterbot.storage.MongoDatabaseAdapter` since SQLite3 isn't supported. To do this simply change the following line:

`english_bot = ChatBot("English Bot", storage_adapter="chatterbot.storage.SQLStorageAdapter")`

... to use the MongoDB adapter:

```
english_bot = ChatBot("English Bot", 
                     storage_adapter = "chatterbot.storage.MongoDatabaseAdapter",
                     database = mongodb_name,
                     database_uri = mongodb_uri)
```
... where `mongodb_name` is the name of the database you wish to connect to and `mongodb_uri` is the URI of a remote instance of MongoDB.

## License
This source is free to use, but ChatterBot does have a license which still applies and can be found on the [LICENSE](https://github.com/gunthercox/ChatterBot/blob/master/LICENSE) page.