'python'에 해당되는 글 15건

If you only want to convert to specific timezone, use localize. and forget normalize.

just use

tz2 = timezone("Asia/Seoul")
dt = datetime.datetime(year=2017, month=4, day=29, hour=8, minute=35, second=10)
dt2 = tz2.localize(dt)
utc_timestamp = dt2.timestamp()

this will calculate including DST time

but If you are going to do arithmetic operation(- or +) to your datetime object and It crosses DST start or end time,

you should use normalize(dt) to fix the utc offset.

refer to

https://github.com/newvem/pytz/blob/master/pytz/tzinfo.py

def normalize():

Error

expires = pickle.load(f)
EOFError: Ran out of input

Solution

remove flask_session folder, and restart flask

ref

https://github.com/pallets/flask/issues/2216

monkey.patch_all(thread=False)

Remove "thread=False".

This makes thread hanging.

Refer to usage of pymongo + gevent on below site

http://api.mongodb.com/python/current/examples/gevent.html

https://stackoverflow.com/questions/7166998/pymongo-gevent-throw-me-a-banana-and-just-monkey-patch

They are telling,

"By default, PyMongo uses threads to discover and monitor your servers’ topology (see Health Monitoring). If you execute monkey.patch_all() when your application first begins, PyMongo automatically uses greenlets instead of threads."

monkey patch all

1. 어느 위치에 써줘야할까?

문서에 보면 가능한 젤 위에 patch all코드를 쓰라고한다. 근데 상식적으로, import 모듈을 해놓고 패치를 해야 로드된걸 패치시키는게 아닐까? 라는 의문을 같게 된다.

대답은 맞다. 그렇지만 맨위에 쓰는게 맞다 이다.

왜냐면, monkey patch 를 지원하는 standard library들은 순서가 어찌되었건 몽키패치를 지원한다. 

from gevent.monkey import is_module_patched
from gevent import monkey;monkey.patch_all()
import socket
import threading
print(is_module_patched("socket"))
print(is_module_patched("threading"))

결과:

True
Ture

import socket
import threading
from gevent import monkey;monkey.patch_all()

print(is_module_patched("socket"))
print(is_module_patched("threading"))

결과:

True
True

그렇지만 몽키패치를 지원하지 않는 3rd library들은 위험할수도 있기 때문에 가급적 패치올을 맨위에 써서 영향이 안가도록 맨위에 쓰라는 것이다.

2. patch_all(thread=False) 

thread patch는 기본적으로 True다. thread가 몽키패치되게되면, threading을 쓰는 부분을 thread가 아니라 gevent에서 지원하는 Greenlet object로 바뀌게된다. 

일단 큰 차이는 context switching 시점이다.

thread는 내가 원하는 시점에 명시적으로 context switching을 하는게 아니라 os 스케줄에 따라서 context switching이 되어 쓸데없는 비용을 소비하게 될 확률이 높다.

그러나 greenlet object는 명시적 sleep이나 library의 io에 패치된 경우에 한해서 context switching이 된다.

참고로, windows 10에서는 maximum recursive error가 나오면서 patch_all 함수가 실패한다. 이때 thread=False 옵션을주면 잘 동작하게 된다. 아마 윈도우10에서는 thread패치를 완벽히 지원하지 않는것 같다. 

reference

1. https://stackoverflow.com/questions/39537004/gevent-monkey-patching-order

2. https://stackoverflow.com/questions/15556718/greenlet-vs-threads

Problem:

 - content length mismatched(ERR_CONTENT_LENGTH_MISMATCH)

 - response string truncated (cut off)

If you are using flask with gevent monkey patch all and you got such a problem above, 

than you should use gevent wsgi instead of flask app.run

For example..

reason:

flask is not for aysnc future model, so if you want to use asynchronous for http or any socket use, than you should use gevent wsgi

If you use http request or something using socket in gevent spawn,
you should make a limit of file open count. use python resource. like this,

import resource
resource.setrlimit(resource.RLIMIT_NOFILE, (1024, 1024))

Otherwise, It will consume all your memory as much as it can by consuming all file count that it can consume as specified on limit.conf (/etc/security/limit.conf)

But requests still consumes a lot of memory.. I just decided to use tornado instead of flask+gevent+requests

reference: http://d.hatena.ne.jp/Malan/20121007

flask + gevent websocket + gunicorn

실행 방법은

gunicorn --bind 0.0.0.0:yourwebsocketport -w 2 -k "geventwebsocket.gunicorn.workers.GeventWebSocketWorker" yourappfilename:app

으로 실행하면 아주 잘 되야한다.

그러나 쟁점은 gunicorn 실행시

if __name__ == "__main__" 에 걸리지 않는다는것이다.

걸리게 하려면 yourappfilename을 __main__대신 넣어주면 된다.

if __name__ == "yourappfilename"

그리고 실행하면 Address already in use를 만날수 있다.

그렇다면 살며시 이부분을 주석처리해준다.

# server = pywsgi.WSGIServer((myIP, config.NOTI_WS_PORT), app, handler_class=WebSocketHandler)
# server.serve_forever()

- 보통 퍼포먼스를 보면 아무래도 pure C기반의 uwsgi가 pure python인 gunicorn보다 빨라보입니다. 간혹 uwsgi가 느리다는 비교가있는데 이는 gunicorn은 워커를 gevent로 하면 몽키패치를 지가 app서버에 해버리는데 반해 uwsgi는 app서버 코드에 몽키패치를 해줘야함을 모르고 테스트할 결과로 보여지네요.

- 사용성 측면에서 uwsgi가 좀더 복잡하고 코어 갯수에 따라 configure를 잘못하면 오히려 성능저하가될 우려가 보이네요.

- 도큐먼트는 gunicorn이 훨깔끔

*참고로 gunicorn, uwsgi모두 앞단에 nginx를 쓰는케이스가 많이 있습니다. 이는
DDos 공격방지, static file전송 효율성등때문이라고 합니다. 그리고 gunicorn document에서도 말하고 있는 nginx buffering기능때문입니다. 

nginx에도 설명이 잘나와있지만 nginx buffering에 대해 좀더 설명하자면,

client - nginx - app servers

이 구조에서 client에 response를 전송하는데 nginx buffer가 없고 클라이언트가 response 패킷을 천천히 받으면 그 영향이 app server한테까지 끼쳐서 그 process는 블락이되어 다른 패킷을 처리 못하게 됩니다. 

하지만 nginx buffer가 있다면 nginx는 app server에게 response패킷을 모두 받을때까지 client에게 응답하지 않고 app server에게 다 받은후 client에게 응답을 보냅니다. 따라서 slow client를 만나더라도 app server는 블락이 되지않을 수 있는것이죠.

*추가로 볼만한것

- Backend Architechtures(https://gist.github.com/ngocphamm/5849994)

- ELB+nginx+appservers(http://amazonwebservices21.blogspot.kr/2015/07/system-architecture-to-deploy-django.html)

Gevent monkey patch makes requests to react asynchronous.

Environment: mac OS 10.11.5, python 3.5.2, gevent==1.1.2, requests==2.12.4

Example:

from flask import Flask

from gevent.pywsgi import WSGIServer
from gevent import monkey

import requests
# need to patch sockets to make requests async
monkey.patch_all()

app = Flask(__name__)  # pylint: disable=invalid-name
app.debug = True


@app.route('/test')
def test(requests_counter=[0]):  # pylint: disable=dangerous-default-value
    """Asynchronous non-blocking streaming of relatively large (14.5MB) JPG
    of Seattle from wikimedia commons.
    """
    requests_counter[0] += 1
    request_num = requests_counter[0]
    url = 'http://www.google.com'
    app.logger.debug('started %d', request_num)
    rsp = requests.get(url)
    app.logger.debug('finish %d', request_num)

    return rsp.text


def main():
    http = WSGIServer(('', 5000), app.wsgi_app)
    http.serve_forever()


if __name__ == '__main__':
    main()

Result:

started 1

started 2

started 3

started 4

started 5

started 6

finish 4

finish 5

finish 3

finish 6

finish 1

finish 2