问Foxx应用程序似乎未编译

EN

很抱歉，我不能共享我的数据。

下面是我在两台机器上测试CouchDB和ArangoDB访问的代码。它是极简主义的，在CouchDB和ArangoDB上都没有引入个人代码，使用超文本传输协议，并在本地工作。

import requests
import time

LOOP = 500

CDB_SESS = requests.Session()
CDB_SESS.stream = False
CDB_SESS.headers.update({'content-type': 'application/json; charset=utf-8'})

ADB_SESS = requests.Session()
ADB_SESS.stream = False
ADB_SESS.headers.update({'content-type': 'application/json; charset=utf-8'})

if __name__ == '__main__':
    print 'CouchDB'
    START = time.time()
    for x in range(LOOP):
        _rsp = CDB_SESS.get('http://localhost:5984/')
        value = _rsp.json()
    STOP = time.time()
    print (STOP - START)

    print 'ArangoDB'
    START = time.time()
    for x in range(LOOP):
        _rsp = ADB_SESS.get('http://localhost:8529/_db/_system/_api/version')
        value = _rsp.json()
    STOP = time.time()
    print (STOP - START)

这两个循环的不同之处仅在于所使用的url。数据库只运行内部代码，不是我的，对吧？

如果瓶颈来自Python或请求，那么这个瓶颈在两个数据库上的作用方式是相同的，这不是很合理吗？

今天，我把PC放在一边，开始研究MAC。

我卸载了ArangoDB (brew卸载arangodb)，并清除了目录var/lib中的内容。然后我重新安装了它(brew安装arangodb)，没有传输我的数据或任何Foxx应用程序。One virgin install我唯一的操作是修改v8-context=1。

我启动了上面的测试，3次。结果如下：

• CouchDB: 1.54s、1.49s、1.05、1.04s、1.05s

结果和以前得到的结果一样糟糕。

我是否必须牵连我的数据(不存在)或我的Foxx应用程序(不存在)？

我做了一些测试。

我在两台机器上使用的版本是相同的：

• CouchDB 1.6.1
• ArangoDB 2.7.3
• requests 2.9.1

除了python:

• PC 2.7.6

• MAC 2.7.11

两台机器上的测试代码是相同的。我发射了3次，以防万一。CouchDB和ArangoDB上的数据在PC和MAC上是相同的。

第一个测试是一个仅在CouchDB上读取500条记录的循环(我的源代码)：

PC上的

• ：53.36s、53.66s、53.59s MAC上的
• ：5.70s、5.86s、6.01s

MAC的速度是它的9-10倍。速度减慢不是来自我的数据源，对吧?

第二个测试是在CouchDB上循环500 'http://localhost:5984/‘，在ArangoDB上循环500 'http://localhost:8529/ system/_ api/version’。我的代码不会干预，对吧?：在PC上：

20.01s

• ArangoDB：

• CouchDB: 20.02s，20.01s，0.48s，0.37s，0.38s

“哪一个是你的版本？”的速度差异？大约是40。

在MAC上：

• CouchDB: 1.48s、1.49s、1.07秒、1.07秒、1.13秒

区别在哪里?

经过大量的研究和讨论，我们发现了两个问题：

我们用于API文档的

• swagger.io花了很长时间才能在safari中渲染；我们更新到了更新的版本。
• 苹果引入了一个性能回归的El Capitans xcode & clang，它使ArangoDB的速度慢了7倍。使用较旧的xcode或GCC不会产生较慢的binaries.The latest formular now strongly discourages using clang

进行了进一步的讨论in github issue #1629