2011-05-17 163 views
2

我有一个每三分钟运行一次的cron作业,它会从远程API抽取一些数据,然后将其存储在本地数据存储中。但是,这会在数据存储放置操作中占用大量的CPU时间。我怀疑我可能做一些非常愚蠢的,可优化很多:如何最大限度地减少数据存储使用的CPU时间

result = urllib2.urlopen(url).read() 
foos = json.loads(result)['foo'] 
bars = json.loads(result)['bar'] 

models = [] 
for foo in foos: 
    d = FooContainer() 
    d.Property = foo.Value #in real code, this is setting a load of values based off foo  
    models.append(d) 

for bar in bars: 
    d = BarContainer() 
    d.Property = bar.Value #in real code, this is setting a load of properties based off bar 
    models.append(d) 

db.put(models) 

正如你所看到的,我存储每一块回来在我的本地数据表的新“行”的数据。是否有一些技术可以用来减少此cron作业使用的大量数据存储CPU时间?

+0

您要保存多少个实体? – systempuntoout 2011-05-17 12:13:23

+0

最新工作保存了217个小时和137个小节。大多数工作将大致相同 – Martin 2011-05-17 12:24:53

回答

6

〜2k cpu_ms看起来正确。您看到46k api cpu_ms,因为数据存储区只能写入最大值。每秒10个实体(由api控制),并且您正在编写450多个实体,因此450+/10约为46k cpu_ms。

api的使用情况不会直接计入您的配额底线,只有real〜2k会计。所以不要担心,你就好。

+0

因此,尽管appengine控制台警告我每次这个cron作业运行时平均使用59070,那么这真的没有关系? – Martin 2011-05-17 13:49:14

+1

注意你的输出中有'real'和'api'。 “真实”会计入您的配额。 'real'是完成的实际cpu工作,以一个虚拟的1.2GHz CPU为单位以毫秒为单位进行测量(有关详细信息,请参阅appengine文档)。现在,如果你发现'real'类似于59k + cpu_ms,那么你有一个问题,但是你只有2k,而这是每3分钟一次,所以这个例程只会使用你的免费配额的一小部分。 – 2011-05-17 15:19:46

-7

您是否尝试过使用nice来对别人过程好?

http://en.wikipedia.org/wiki/Nice_%28Unix%29

而且,可以肯定的你正在做批量插入,但似乎如此。

+1

不错,适用于appengine? – Martin 2011-05-17 09:57:28

+3

应用程序引擎没有“不错”的概念。可怕的答案。 – 2011-05-17 13:12:06

1

这个放置很好。真的,你可能会犯错误的唯一方法是使用太多的RPC。你已经在使用一个。

在一个请求处理程序中存储〜400个实体将会很昂贵。如果你想优化,我会问自己,你是否真的需要一次存储多个实体。你能否更频繁地运行cron作业并返回更小的批次?你实际上每行需要一个实体,还是可以用较少的实体和ListProperty完成同样的事情?您的问题中没有足够的背景提供可行的建议,但需要考虑。

相关问题