Another way to make Python web app do concurrency

I'm developing a Python web app that emulate WifiDog for remote demo purpose. It is not just a normal web app because it has to run 2 jobs as the same time:

  • Run as a webserver, to redirect user visit to the URL of WifiDog's remote Auth Server.

  • Periodically report system state to Auth Server as a normal HTTP request.

Make the first one is easy. The web part actually don't have much thing to do. It only builds some URL and redirect user to. A small script based on Bootle is enough. What make me concern is the second requirement. Normally, when I build a website on Django or Flask and I need the web do some periodic task, I just use Celery. But here I don't want to use Celery because Celery require me to run another command (celery) beside the main one (which is to launch my web app). Using Celery also means that I have to install more programs like RabbitMQ. It is a waste for just a small, simple web app.

Thay thế firmware cho router wifi bằng OpenWrt

Giả sử bạn có router wifi mà bỗng một ngày bạn thấy nó hơi nghèo nàn, thiếu tính năng mới lạ, hay đơn giản là bạn thấy cuộc sống quá yên bình nên muốn chọc ngoáy cái router đôi chút, như bạn từng thử cài hàng tá phần mềm lên PC, thay đổi cấu hình này nọ thành một mớ hỗn độn rồi phải cài mới lại hệ điều hành. Nếu bạn cảm thấy như thế thì có thứ rất đáng cho bạn cài vào router và thử đấy.

Cài phần mềm lên router à, cũng được nữa sao? Tôi đâu thấy có màn hình, bàn phím trên router đâu?

Đa số các router wifi hiện nay thực ra cũng là là một máy tính thu gọn (ngoại trừ router của Cisco thì tôi không chắc lắm vì chưa đụng vào bao giờ). Nó cũng có mainboard, CPU, RAM, chip wifi. Nó không có ổ cứng vì người ta không cần lưu trữ dữ liệu trên nó, thay vào đó nó dùng bộ nhớ Flash (tương tự điện thoại di động) để chứa các chương trình. Chúng cũng chạy hệ điều hành và hầu hết hệ điều hành này là phiên bản tỉa bớt của Linux. Nhà sản xuất cắt bỏ và thay đổi nhiều thành phần của Linux để đảm bảo dung lượng nhỏ và không để "cửa" cho người dùng chọc ngoái nhiều. Vì không có màn hình bàn phím nên ta chỉ có thể điều khiển máy tính thu gọn này từ một máy khác (PC của ta), thông qua giao diện web hay giao diện dòng lệnh (telnet).

Như đã nói ở trên, hệ điều hành trong router đã bị cắt gọt nhiều, nên nhiều người mua là dân công nghệ (đúng nghĩa là dân công nghệ chứ không phải dân ưa mua sắm đồ chơi công nghệ đắt tiền để thể hiện) cảm thấy gò bó trong giới hạn của phần mềm mà nhà sản xuất cung cấp trong router. Họ muốn tùy ý phát triển chức năng của router mà không phải tốn tiền mua router đắt hơn. Họ thấy phần mềm có sẵn bị lỗi và muốn phần mềm mới hơn có thể khắc phục lỗi ấy. Thế là OpenWrt ra đời.

Sự chia cắt của Việt Nam dưới thời Pháp

Ngày xưa học lịch sử ở trường, vẫn nghe rằng thực dân áp dụng chính sách "chia để trị", rằng dưới thời Pháp, nước ta bị chia thành 3 kì: Bắc Kì, Trung Kì, Nam Kì. Tuy nhiên, mình hồi đó vẫn chưa hiểu nổi sự chia cắt đó, 3 "kì" đó ngăn cách nhau ra sao, vì nhìn quanh thời nay thấy người ta vẫn chia ra mà gọi thành "miền Bắc", "miền Trung", "miền Nam" mà có thấy gì là "chia cắt" đâu, vẫn là 1 đất nước dưới cùng 1 chính quyền, 1 lá cờ, 1 quốc ca.

Rồi nhân cách đây mấy hôm ngồi giải thích cho thằng bạn lí do Sài Gòn - Tp HCM giàu hơn Hà Nội, hay miền Nam nói chung lại giàu hơn miền Bắc, dù Hà Nội là thủ đô thì vấn đề chia cắt này lại được nêu lên, như 1 trong các lý do dẫn đến sự thịnh vượng của Sài Gòn, miền Nam.

Vậy 3 miền đó bị phân biệt nhau thế nào dưới thời Pháp?

Liên bang Đông Dương

Thiết bị mã hóa, smartcard và OpenSC (phần 1)

Tôi mới quay trở lại phát triển tiếp CryptoStick, sau 1 năm gián đoạn. Thực ra công việc của tôi không phải là phát triển phần cứng hay firmware cho nó, mà là mở rộng bộ phần mềm OpenSC để nó có thể nói chuyện, khai thác CryptoStick nói riêng và mọi smartcard theo chuẩn OpenPGP nói chung.

Thế CryptoStick là gì?

CryptoStick là một loại thiết bị có hình dáng giống bút nhớ USB (pen drive, USB key), nhưng thay vì để lưu trữ dữ liệu như bút nhớ thì nó làm công việc mã hóa, giải mã dữ liệu. Dữ liệu được chuyển vào CryptoStick ở dạng nguyên bản rồi được lấy ra ở dạng đã được mã hóa, hoặc ngược lại.

CryptoStick

Flask-SQLAlchemy consuming 100% CPU with multi-thread WSGI server.

These days I has been taking my hairs with a critical issue on my web app, when it eats up to 100% CPU of my VPS.

My web app plays role as an authentication server for splash-protected Wifi network. When people want to use the network, the router (with WifiDog installed) will drive them to a login page first, requiring them to authenticate to get Internet access. With this usage, I don't expect the server to get too many guests. That's why I chose to build it with Flask. For database utilization, I pick SQLAlchemy for safety and because at that time, none of others supports Python3.

The website runs smoothly until one recent day we realized that it took 100% CPU and made the server irresponsive. I tried many ways, including rollbacking the code to old revisions, downgrading the libraries but none helps. At first I ran with CherryPy as WSGI server, then I tried switching to Waitress. No help. When I ran with Flask's built-in Flask server, I noticed that the CPU usage no longer increased to 100%, but in other hand, the web kept hanging. The browser could connect and make HTTP request, but got no response.

After many days trying and testing as well as doing optimize code which exploits database, I try the last option: switching to Gunicorn. Surprisingly, this helps! Though I don't know how Gunicorn fix the problem, or where is the defect in my code, I can assert that it is not because "Gunicorn is superior to others". The difference between Gunicorn and the other forementioned is that one is multi-process type and one is multi-thread (CherryPy, Waitress). My use, my setup of SQLAlchemy/PostgreSQL is somehow compatible with multi-process server rather than multi-thread. But by which manner, I don't know. There are many of setup of Flask+SQLAlchemy+CherryPy out there but no one complaints about 100% CPU issue. It proves that the issue is not CherryPy/Waitress's fault.