就 @serial

关于数据处理，这眼界也真是 [狭窄] 得令人无语，你做不到不代表别人做不到啊，
国外就不说了，公开资料来看国内的豆瓣就用 Python 重写 Spark 处理数据啊
https://www.douban.com/subject/10774736/


你自己慢慢看吧。如果非要抬性能的杠也没啥意思，你用啥觉得性能好就用啥呗，俗话说 u can u up 嘛。
在 Sun 没有收购 HotSpot 技术前， Java 性能也被人诟病，又如何，即便现在 C/C++程序员可能还对 Java 有偏见，
但并不影响开源社区用它去做分布式和大数据应用！

还有，代码写不好不要怪语言和编译器，多反思自己用的技术是不是很契合自己的应用场景，换句话说你用 C 撸了一堆所谓 [高效] 的代码，速度在优于 Python ，实现的玩意不值钱，有个逑用。

k8s 是好，不敢用啊…

可以写个简单的 agent 到应用服务器上收集状态信息发送到你的监控代理上，也可以由监控代理主动去请求应用的接口或页面做状态判断。
服务器监控的常见手段么，无非是： SNMP 、 WMI 、 HTTP Get 、 PING 等， lz 可以去了解下 Zabbix 等开源监控系统的架构

@dzhou121 终于有明白人粗来说话了～ 唉.

@liangmishi
看情况，假设你用的是 mysql ，如果是数据库表死锁了导致的，那么在解锁前你就查不了了。这跟 Python 、 django 框架没啥关系的。
还有种可能就是数据库连接资源被吃光了，无法释放多余的连接给你的 client ，发生这种情况就要找你们的 dba 看下查询提交状态了， kill 掉慢查询或重启……

@serial 你 bb 那么多能证明啥，证明你完虐 Python ，怒骂设计不合理 还是你智力有很高？ 傻逼

@serial 忘记 at 了

不管你说啥，俺就一个观点： [ IO 阻塞与否跟编程语言没多大关系的， OS 、各类服务 driver 不支持的话，众多编程语言一起哭吧]

没必要把一些库搬出来证明啥，其实啥也证明不了。也麻烦你仔细看俺跟你辩的到底是啥嘛。

ps:在网络上话多措辞强硬有得罪请见谅。希望接下来的辩论，不会让 v2 风气变得太差。
窃以为这种问题帖要学术些、实证些而非诡辩、争吵。伤人不太了。

@serial 放一堆链接有啥用，明眼人一看就知道你吐槽的东西根本就不在点子上
首先要搞懂操作系统基本知识、并发、异步基本的东西再辩吧。

不是贴的文字内容越多，越有道理的。

记得 celery 也是 >_<

unicodeobject 对应实现为：
static PyObject *
unicode__sizeof__(PyUnicodeObject *v)
{
return PyInt_FromSsize_t(sizeof(PyUnicodeObject) +
sizeof(Py_UNICODE) * (v->length + 1));
}

看了下代码，关于这个__sizeof__方法不同对象提供的方法不同，其中你要的 stringobject 的实现：

static PyObject *
string_sizeof(PyStringObject *v)
{
Py_ssize_t res;
res = PyStringObject_SIZE + v->ob_size * v->ob_type->tp_itemsize;
return PyInt_FromSsize_t(res);
}

其中 v->ob_size 是实际长度（ byte ），
PyStringObject_SIZE 相当于 sizeof(PyStringObject)，
tp_itemsize 为 sizeof(char)

代码版本： CPython 2.7.x

@justou 官方邮件组说不同平台返回结果可能不同

@xinali 你没看懂我意思么，意思就是说你这么算 unicode 长度是不对的， len 和__sizeof__ 不是一个概念。

@serial 建议你好好去阅读这些 driver 的源码（因为你总是说他们基于 httplib ，你呼它出来谈谈，问问它在这些 driver 实现里干啥呢），还有 IO 阻塞与否跟编程语言没多大关系的， OS 、各类服务 driver 不支持的话，众多编程语言一起哭吧。
Python 如果会讲话肯定会吐槽：“ C/C++原生撸 driver 本来就特么没有给俺做 none blocking 实现，怪我咯？”

建议你好好读一读 CSAPP 看看到底啥是 IO 多路复用，不理解再辩。

__sizeof__是 2.6+版本支持的，但不作为生产环境用途， 与之相关功能说明请参考文档中的： sys.getsizeof ，它不是用来计算 string 长度的！

@serial 同学，非阻塞 vs 异步是俩种概念额…… 不明白为啥又把各路框架、性能扯到可移植性来了。
@FrankHB 这里说的 native 指的是 x86 汇编…没深入研究过 SIMD 指令集，极端的说，比起虚拟机语言，操作指令集让性能更可控而已

歪了楼，极端点讲，一门基于虚拟机的语言与 C 、汇编相比能否充分压榨机器的极限，坦率的讲我个人觉得现有的编译技术够呛可以做到满分。

你再模拟，跟 C 、汇编这类贴近机器硬件的语言相比，大部分相同的功能操作也是要多出几个指令、周期的，不管跑在纯 Runtime 环境还是 JIT 编译后的，很难做到完美的优化你的机器指令！

因此，用虚拟机语言撸代码，还是别想着这些东西了，编译过程的优化你根本没法控制，个人 /团队做项目按时交付能愉快地给老板们创造价值才是王道。 不说了，睡觉明儿早起继续搬砖了。

@serial 关于"并发 IO === 渣"的推论很有趣，立论不太对吧。
CPython 本质上是使用 C 实现的 fs 操作部分，渣，你要说渣在何处嘛。
还有你说的异步支持， IO 多路复用的部分例如 select 模块也是用 C 实现的呀，代码你可以去瞅瞅呀，凭啥说渣呢，你要这么说 Twisted 超级脚手架就不开心了，已哭晕在厕所…
我实在想不通你举几个例子就论证人家渣是啥根据。你不能看到“苹果园果树打了农药” 就到处去跟人家说 “任何树上的苹果都被喷了农药”呀，要根据情况去论证和检验下嘛。