环境准备假设有一台远程服务器：1.2.3.4，上面运行着一个socks5代理：127.0.0.1:1080。登上这台远程服务器后，可以通过curl验证这个代理： 123456$ curl --socks5 127.0.0.1:1080 https://httpbin.org/get{ ... "origin": "1.2.3.4", ...&

前言 因为一些不可描述的原因，在中国绝大多数地区进行更新APT软件包列表（apt-get update）&安装APT软件包（apt-get isntall）、拉取Docker镜像（docker pull）、安装PyPI包（pip install）等操作都是一件非常痛苦的事：网络连接速度太慢了。万幸的是我们有许多开源软件镜像站点，合理设置镜像站点能够极大提升工作和学习效率。这篇文章介绍的就是

前言ownCloud一直是市场上最受欢迎的个人云存储解决方案之一，有着使用广泛、客户端兼容性好、自由开源等优点。但ownCloud的部署涉及LAMP环境，部署过程较为繁琐。这篇文章介绍如何用docker-compose快速部署ownCloud，并配置Nginx转发+HTTPS提高服务器安全性。 配置docker-compose 以下部分内容来自ownCloud官方安装文档 首先，下载官方dock

前言用工具测试下手头用着的linux server，三个vps平台、一台物理机，测试结果看看就好，不用太较真。 测试结果汇总 服务商 Google Cloud Google Cloud 阿里云 某NAT VPS商家 个人PC 机器型号 f1-micro 1vCPU 0.6GB 10GB g1-small 1vCPU 1.7GB 40GB ecs.n4.small 1vCPU 2GiB 4

前言开源项目Kong是当下最火的API Gateway项目之一，官方也在Docker Hub上提供了Kong的镜像。但我在使用官方镜像来部署Kong的过程中发现，我需要对官方镜像做一些改动来适应我的需求： 在Docker启动时只需要给定镜像、启动命令即可完成部署（包括初次部署），方便迁移k8s； 方便Kong切换不同的配置文件； 将Kong所有的日志存放在指定目录，方便挂载存储。 这篇文章记录

前言不存在没有BUG的代码，也不存在不会出现异常的视图函数。当Django视图函数中的代码出现异常时，访问这个URL的用户就会收到状态码为500 Internal Server Error的HTTP 响应。如何捕捉视图函数里出现的异常，这是本篇文章要讨论的问题。 注：本文所使用的运行环境为uWSGI 2.0.18+Python3.6+Django 2.2 在uWSGI的日志中显示Traceba

前言虽然根据经验来看，许多简单Django应用的性能问题都来源于数据库IO（而这可以通过聚合查询等手段进行优化），但premature optimization is the root of all evil，定位性能问题的具体位置仍然是最应该先做的事。和其它相对独立的Python代码不同，Django的视图函数代码与Django框架的耦合度很高，这给对代码的性能分析带来了一些困难。但幸运的是，D

前言在前一篇文章中，我介绍了测量执行Python代码所需要的总体时间的几种方法。而在实际的性能分析场景中，目标代码的逻辑往往比较复杂，光靠总体执行耗时并不能帮助我们快速定位性能瓶颈。这个时候就需要请出Python的标准库：cProfile（官方文档）来对代码进行细致的性能分析了。和前一篇文章一样，本文所使用的测试平台为Ubuntu 18.04+Python 3.6，并使用代码文件slow_func

前言我们怎样知道执行某个Python文件、某个函数、某段代码所耗费的总体时间？这是这篇文章尝试去回答的问题。作为样例，本文使用slow_func.py来进行性能分析，内容如下： 1234567891011121314# coding:utf-8import timeimport randomdef func1(): time.sleep(1) # 等待一秒def func2(): f

前言在实际部署Python Web应用时，我们往往会采用类似Nginx->uWSGI/Gunicorn->Python的三层架构。使用Nginx而不是直接使用uWSGI来处理HTTP请求的理由主要有以下几点： Nginx更安全； 需要实现负载均衡/URL转发； Nginx处理静态文件更快，缓存头更完善。 但在某些诸如简单Web应用、外部统一网关、单机单容器、内网环境等部署