客户端在深度复制上花费了很长时间

Question

我有一个Python用户，有时从Bigtable中读到的东西非常慢。它从Bigtable读取一行，执行一些计算，并偶尔将一些信息写回，然后继续。

问题是，在GCE中的1 vCPU VM中，它的读写速度非常快，消费者会咀嚼100到150条消息/s，没有问题。

然而，当部署在多区域(europe-west1-b/c/d)的生产Kubernetes集群(GKE)上时，它会经历0.5条消息/s.是-2每条消息.

Bigtable在europe-west1-d中，但是调度在同一区域(d)节点上的豆荚具有与其他区域中的节点相同的性能，这是很奇怪的。

吊舱不断达到CPU的极限(1 vCPU)。对程序的分析表明，大部分时间(95%)都是在PartialRowData.cells()函数的内部，在copy.py:132(deepcopy)中

它使用最新的google-cloud-bigtable==0.29.0软件包。

现在，我知道包在alpha中，但是是什么因素使性能大幅度下降了300倍呢？

读取行数据的代码如下：

def _row_to_dict(cls, row):
    if row is None:
        return {}

    item_dict = {}

    if COLUMN_FAMILY in row.cells:
        structured_cells = {}
        for field_name in STRUCTURED_STATIC_FIELDS:
            if field_name.encode() in row.cells[COLUMN_FAMILY]:
                structured_cells[field_name] = row.cells[COLUMN_FAMILY][field_name.encode()][
                    0].value.decode()
        item_dict[COLUMN_FAMILY] = structured_cells

    return item_dict

row传入的位置是

row = self.bt_table.read_row(row_key, filter_=filter_)

可能有50 STRUCTURED_STATIC_FIELDS左右。

深度复制真的需要很长时间才能复制吗？还是在等待Bigtable的数据传输？我是不是在滥用图书馆？对如何提高性能有什么建议吗？

提前谢谢。

Answer 1

结果，库将row.cells的getter定义为：

@property
def cells(self):
    """Property returning all the cells accumulated on this partial row.

    :rtype: dict
    :returns: Dictionary of the :class:`Cell` objects accumulated. This
              dictionary has two-levels of keys (first for column families
              and second for column names/qualifiers within a family). For
              a given column, a list of :class:`Cell` objects is stored.
    """
    return copy.deepcopy(self._cells)

因此，除了查找之外，每个对字典的调用都要执行一个deepcopy。

添加一个

row_cells = row.cells 

后来只提到了这个问题。

dev/prod环境的性能差异还使用了以下事实: prod表已经有了更多的单元格时间戳/版本，而dev表只有两个单元格。这使得那些必须被深拷贝的词典变得更大了。

将现有的过滤器与CellsColumnLimitFilter链接在一起更有帮助：

filter_ = RowFilterChain(filters=[filter_, CellsColumnLimitFilter(num_cells=1)])