一、引言

作為國(guó)內(nèi)領(lǐng)先的在線視頻平臺(tái)，嗶哩嗶哩（以下簡(jiǎn)稱“B站”）正經(jīng)歷著業(yè)務(wù)體量和用戶規(guī)模的快速增長(zhǎng)。隨著訪問量的持續(xù)增長(zhǎng)和業(yè)務(wù)復(fù)雜程度的增加，在相對(duì)有限的服務(wù)器資源下如何優(yōu)化在線服務(wù)性能和提高資源利用率，成為了工程研發(fā)團(tuán)隊(duì)面臨的重要挑戰(zhàn)之一。

本文將以筆者所在的商業(yè)技術(shù)中心為例，重點(diǎn)討論效果廣告引擎的在線推理部分。文章將分享筆者在實(shí)際工作中遇到的挑戰(zhàn)及相應(yīng)的優(yōu)化方案。首先，將介紹項(xiàng)目背景和當(dāng)前系統(tǒng)的運(yùn)行狀況；接著，將詳細(xì)探討性能指標(biāo)量化、服務(wù)調(diào)用、CPU計(jì)算、內(nèi)存治理及網(wǎng)絡(luò)IO等方面的優(yōu)化策略；最后，將總結(jié)對(duì)性能優(yōu)化的一些思考，并展望未來性能優(yōu)化的方向。本文的目的是回顧并總結(jié)當(dāng)前在線服務(wù)性能優(yōu)化的工作，同時(shí)也希望這些經(jīng)驗(yàn)?zāi)転槠渌邪l(fā)人員在處理類似問題時(shí)提供參考和啟發(fā)。

二、項(xiàng)目背景

筆者所在的團(tuán)隊(duì)主要負(fù)責(zé)在線效果廣告引擎的研發(fā)工作，該服務(wù)作為商業(yè)化系統(tǒng)的重要組成之一，為公司帶來了實(shí)質(zhì)性的商業(yè)貢獻(xiàn)。通過精準(zhǔn)高效的廣告投放，能夠?yàn)楣編矸€(wěn)定且可觀的廣告收入，成為支撐平臺(tái)發(fā)展的關(guān)鍵營(yíng)收來源之一，進(jìn)一步支持了平臺(tái)的內(nèi)容創(chuàng)新和技術(shù)研發(fā)，構(gòu)成良性循環(huán)。對(duì)于廣告主而言，效果廣告引擎提供了精準(zhǔn)定向用戶的能力，顯著提升了廣告?zhèn)鞑サ男Ч瑸槠鋷砀叩膹V告轉(zhuǎn)化和投資回報(bào)。對(duì)于用戶而言，通過更貼近用戶行為習(xí)慣的廣告投放，確保了廣告內(nèi)容與用戶興趣和需求的高度匹配，最大限度地保障了用戶體驗(yàn)。

隨著效果廣告業(yè)務(wù)的快速發(fā)展，處理的業(yè)務(wù)復(fù)雜度不斷提升，對(duì)在線服務(wù)的處理效率和吞吐量提出了更高要求。同時(shí)，B站的用戶規(guī)模和使用時(shí)長(zhǎng)的持續(xù)增長(zhǎng)也加大了這一挑戰(zhàn)。以在線推理服務(wù)為例，它需要對(duì)廣告創(chuàng)意候選集進(jìn)行一系列預(yù)估打分，主要包括特征計(jì)算和模型計(jì)算兩個(gè)環(huán)節(jié)。特征處理階段涉及用戶和廣告數(shù)據(jù)的提取、過濾、拼接等操作，隨著特征數(shù)據(jù)的深入挖掘和應(yīng)用，所需要處理的數(shù)據(jù)量也在不斷增加。在模型計(jì)算階段，支持的模型類型從LR、FM模型逐漸升級(jí)到DNN模型，增強(qiáng)了模型的表達(dá)能力，但同時(shí)也加大了算力資源的消耗。類似的資源開銷增長(zhǎng)問題也存在于效果廣告引擎的其他服務(wù)中。因此，工程研發(fā)團(tuán)隊(duì)面臨的挑戰(zhàn)在于如何有效地對(duì)效果廣告引擎進(jìn)行性能優(yōu)化，確保在硬件資源相對(duì)有限的情況下，依然能夠支持并促進(jìn)業(yè)務(wù)的持續(xù)增長(zhǎng)。

三、系統(tǒng)現(xiàn)狀

首先需要介紹一下效果廣告引擎的系統(tǒng)構(gòu)成，主要包含了以下幾個(gè)服務(wù)：

檢索引擎：作為廣告業(yè)務(wù)的入口，接受來自各個(gè)調(diào)用方的請(qǐng)求，并且會(huì)對(duì)流量進(jìn)行預(yù)處理，其中包括對(duì)流量進(jìn)行實(shí)驗(yàn)分組和標(biāo)記。

效果廣告檢索服務(wù)：作為效果廣告的業(yè)務(wù)核心，負(fù)責(zé)對(duì)候選集中的廣告創(chuàng)意進(jìn)行優(yōu)選，并且將勝選的結(jié)果回傳給檢索引擎。

召回/粗排服務(wù)：根據(jù)流量的上下文信息，從所有在投的廣告創(chuàng)意中挑選出一批符合條件的廣告創(chuàng)意，并且進(jìn)行粗排打分，將最終的Top N作為候選集返回給效果廣告檢索服務(wù)。

推理服務(wù)：負(fù)責(zé)對(duì)候選集中的廣告創(chuàng)意進(jìn)行一系列精排打分，將最終結(jié)果返回給效果廣告檢索服務(wù)。

此處需要說明的是，由于本文的重點(diǎn)是在線推理服務(wù)，因此對(duì)于廣告引擎中的其他部分進(jìn)行了大幅簡(jiǎn)化，實(shí)際的效果廣告引擎要更為復(fù)雜。為了進(jìn)一步便于理解，使用下圖來說明簡(jiǎn)化后的效果廣告引擎內(nèi)部各服務(wù)之間的調(diào)用關(guān)系及主要功能模塊：

圖1 效果廣告引擎調(diào)用關(guān)系及主要功能模塊

目前效果廣告引擎的在線集群規(guī)模已經(jīng)達(dá)到了數(shù)千臺(tái)服務(wù)器，其中在線推理服務(wù)的CPU資源占比約為整體的45%，召回/粗排服務(wù)占比約為21%，效果廣告檢索服務(wù)占比約為10%。通過CPU資源的分配比例，可以直觀反映出各服務(wù)之間計(jì)算復(fù)雜度的差異，同時(shí)也揭示了系統(tǒng)中存在的潛在性能瓶頸。推理服務(wù)作為系統(tǒng)資源開銷最大的在線服務(wù)，對(duì)其進(jìn)行性能優(yōu)化的收益也是最為顯著的。

在對(duì)效果廣告引擎的背景及現(xiàn)狀有了初步的了解之后，下面本文將針對(duì)推理服務(wù)的各項(xiàng)優(yōu)化手段進(jìn)行更為詳細(xì)的介紹。

四、優(yōu)化手段

在實(shí)際工作中，對(duì)于在線服務(wù)的性能優(yōu)化首先要建立在性能度量的基礎(chǔ)上，因此在開始優(yōu)化之前，需要對(duì)在線服務(wù)的各項(xiàng)數(shù)據(jù)指標(biāo)進(jìn)行可量化的測(cè)量和分析。

性能指標(biāo)量化

從宏觀角度來看，可以通過埋點(diǎn)的方式對(duì)在線服務(wù)的各個(gè)模塊耗時(shí)進(jìn)行監(jiān)控和分析，定位到耗時(shí)較高的模塊。之后，可以通過更細(xì)粒度的埋點(diǎn)或者日志，來找到開銷較高的操作，并進(jìn)行性能優(yōu)化。同時(shí)作為在線服務(wù)，效果廣告引擎的各服務(wù)之間的調(diào)用耗時(shí)也是需要監(jiān)控的。受益于服務(wù)使用的BRPC框架，效果廣告引擎的子服務(wù)都實(shí)現(xiàn)了較為完善的監(jiān)控指標(biāo)，包括各模塊之間的平均耗時(shí)、中位數(shù)耗時(shí)、97線耗時(shí)等，并且對(duì)于各類遠(yuǎn)程調(diào)用也都有對(duì)應(yīng)的耗時(shí)監(jiān)控指標(biāo)。依靠這些能夠被量化的數(shù)據(jù)，我們能夠快速定位到哪些模塊和調(diào)用的耗時(shí)較高，并且能夠在開發(fā)人力有限的情況下，給出性能優(yōu)化的先后順序，盡可能提高單次性能優(yōu)化的收益。需要特別注意的是，在確保性能指標(biāo)不失真的前提下，可以對(duì)性能指標(biāo)的收集和上報(bào)進(jìn)行一定程度的采樣操作，主要是為了防止性能度量本身給服務(wù)帶來過大的額外算力開銷。

服務(wù)調(diào)用

在得到較為完善的性能指標(biāo)之后，就可以結(jié)合對(duì)于推理服務(wù)的業(yè)務(wù)理解，從業(yè)務(wù)流程和服務(wù)調(diào)用的角度對(duì)在線服務(wù)進(jìn)行全局分析。這部分的優(yōu)化思路主要是在處理一次用戶請(qǐng)求的過程中，減少數(shù)據(jù)的重復(fù)計(jì)算，并且降低數(shù)據(jù)傳輸?shù)某杀尽?/p>

在較早的設(shè)計(jì)中，效果廣告檢索服務(wù)會(huì)將候選集中的廣告創(chuàng)意拆分成多個(gè)推理請(qǐng)求，并行發(fā)送給多個(gè)推理服務(wù)節(jié)點(diǎn)，從而確保單個(gè)請(qǐng)求的處理耗時(shí)不會(huì)較高。如上文所述，推理服務(wù)需要獲取用戶側(cè)的數(shù)據(jù)來進(jìn)行特征處理，這些數(shù)據(jù)存放在Redis集群中。因此在處理每一個(gè)推理請(qǐng)求時(shí)，推理服務(wù)都需要單獨(dú)訪問一次Redis來獲取用戶數(shù)據(jù)，造成了Redis服務(wù)端訪問較多，并且數(shù)據(jù)重復(fù)傳輸?shù)膯栴}。通過將訪問Redis的操作上移至廣告檢索服務(wù)，然后再發(fā)送給推理服務(wù)的方式，有效減少了對(duì)Redis服務(wù)的訪問量，降低了Redis服務(wù)端的算力開銷和網(wǎng)絡(luò)IO開銷。

此外，在對(duì)早期方案重構(gòu)的過程中，我們對(duì)服務(wù)調(diào)用之間所使用的數(shù)據(jù)格式也進(jìn)行了升級(jí)，將原本類似JSON的數(shù)據(jù)處理方式，升級(jí)成了基于Protobuf3的數(shù)據(jù)處理方式。相比于文本格式的JSON，PB編碼的數(shù)據(jù)通常更小，并且擁有更快的序列化和反序列化速度，這在處理大量數(shù)據(jù)時(shí)尤其重要。同時(shí)，將推理請(qǐng)求中的字段類型與特征計(jì)算中所需要的數(shù)據(jù)類型進(jìn)行對(duì)齊，減少了大量的字符串轉(zhuǎn)化及數(shù)據(jù)校驗(yàn)操作，降低了CPU算力開銷。

這一類問題看似比較基礎(chǔ)，但是在早期引擎架構(gòu)快速迭代的過程中，由于不同階段的各種原因，導(dǎo)致各個(gè)服務(wù)之間的設(shè)計(jì)無法完全一致，一些細(xì)節(jié)問題是比較容易被忽略的。隨著業(yè)務(wù)的迭代和增長(zhǎng)，這類小問題的影響就會(huì)被逐漸放大，導(dǎo)致服務(wù)性能下降和算力資源浪費(fèi)。因此，定期對(duì)在線服務(wù)的業(yè)務(wù)和架構(gòu)進(jìn)行梳理回顧，是保障服務(wù)健康穩(wěn)定的重要手段之一。

CPU算力

將視角聚焦到推理服務(wù)中，對(duì)于單次推理請(qǐng)求，我們同樣也可以使用減少數(shù)據(jù)重復(fù)計(jì)算的方式來降低CPU算力開銷，并且可以使用Perf性能分析工具，來進(jìn)一步優(yōu)化熱點(diǎn)函數(shù)的算力開銷。

首先在進(jìn)行特征計(jì)算的過程中，包含了對(duì)于用戶側(cè)特征和廣告?zhèn)忍卣鞯奶幚恚渲杏脩魝?cè)特征的計(jì)算結(jié)果是能夠被重復(fù)使用的。在推理服務(wù)的處理過程中，單次請(qǐng)求中的多個(gè)廣告創(chuàng)意，會(huì)使用多線程并行的方式進(jìn)行處理，此時(shí)會(huì)先將用戶側(cè)數(shù)據(jù)與單個(gè)廣告創(chuàng)意進(jìn)行計(jì)算，將結(jié)果存儲(chǔ)在特征計(jì)算的運(yùn)行時(shí)對(duì)象中，并且通過標(biāo)記來區(qū)分用戶側(cè)特征和廣告?zhèn)忍卣鳌Ｈ缓螅瑢⑵渲械挠脩魝?cè)特征計(jì)算結(jié)果復(fù)制到其他線程的運(yùn)行時(shí)對(duì)象中，再啟動(dòng)線程進(jìn)行并行計(jì)算。這樣既可以使用多線程來提高批量廣告的特征計(jì)算處理速度，又不會(huì)因?yàn)橹貜?fù)計(jì)算用戶側(cè)數(shù)據(jù)而造成額外的算力開銷。

進(jìn)一步的，通過使用Perf性能分析工具，可以觀察到具體某段代碼的執(zhí)行效率，并且分析出主要的性能開銷點(diǎn)。在實(shí)際工作中，由于推理服務(wù)本身的迭代較為頻繁，我們會(huì)定期對(duì)服務(wù)性能進(jìn)行評(píng)估和回顧。當(dāng)發(fā)現(xiàn)存在性能熱點(diǎn)時(shí)，會(huì)優(yōu)先進(jìn)行性能優(yōu)化，常見的代碼優(yōu)化手段有：

1. 減少分支：分支預(yù)測(cè)失敗會(huì)導(dǎo)致CPU流水線刷新，浪費(fèi)大量的CPU周期。盡可能地減少分支，或者盡量使分支預(yù)測(cè)更加準(zhǔn)確，可以幫助提高代碼的性能。
2. 循環(huán)展開：循環(huán)展開可以減少分支和循環(huán)開銷，同時(shí)也可以提高指令級(jí)并行性。但是也要注意，過度展開可能會(huì)增大代碼體積，對(duì)指令緩存造成壓力。
3. 數(shù)據(jù)局部性優(yōu)化：盡可能地保持?jǐn)?shù)據(jù)的局部性，使得數(shù)據(jù)能夠高效地利用CPU緩存。這包括空間局部性（訪問相鄰的數(shù)據(jù)項(xiàng)）和時(shí)間局部性（短時(shí)間內(nèi)重復(fù)訪問同一數(shù)據(jù)項(xiàng)）。
4. 向量化：利用CPU的SIMD指令集，可以同時(shí)對(duì)多個(gè)數(shù)據(jù)進(jìn)行操作。在編寫代碼時(shí)，盡可能使數(shù)據(jù)結(jié)構(gòu)和算法可以利用SIMD指令進(jìn)行向量化操作。

針對(duì)這些優(yōu)化手段，下面筆者會(huì)提供一些實(shí)際工作中遇到的具體事例以作參考。

1. 使用__builtin_expect內(nèi)建函數(shù)來提供分支預(yù)測(cè)的提示，該函數(shù)會(huì)給GCC編譯器提示，告知其某個(gè)條件判斷的結(jié)果更可能是true還是false，通常用于優(yōu)化代碼中高度可能或者不可能執(zhí)行的分支。在實(shí)際編寫代碼的過程中，該函數(shù)通常與宏一起使用，包括Linux在內(nèi)的各種代碼中都封裝了自己likely和unlikely宏來提高性能。

2. 使用循環(huán)展開來提高代碼性能，下面這段代碼是通過循環(huán)展開來優(yōu)化數(shù)據(jù)構(gòu)建的例子，需要注意的是，當(dāng)批量處理完展開部分的循環(huán)體之后，還需要處理剩余的迭代。

// 循環(huán)展開
for (uint32_t idx = start_idx; idx + 3 < end_idx; idx += 4) {
    result[value[idx]].emplace_back(feaid, ins);
    result[value[idx + 1]].emplace_back(feaid, ins);
    result[value[idx + 2]].emplace_back(feaid, ins);
    result[value[idx + 3]].emplace_back(feaid, ins);
}
// 處理剩余的迭代
for (uint32_t idx = end_idx - (end_idx - start_idx) % 4; idx < end_idx; ++idx) {
    result[value[idx]].emplace_back(feaid, ins);
}

3. 使用函數(shù)指針的方式來減少條件判斷，并且提高時(shí)間局部性，下面是一個(gè)簡(jiǎn)化后的例子。這段代碼的目的是根據(jù)“field_type”獲取“AdInfo”類中對(duì)應(yīng)的成員函數(shù)指針，并且在一個(gè)循環(huán)中對(duì)“ad_info_list”集合中的每一個(gè)“AdInfo”對(duì)象調(diào)用這個(gè)成員函數(shù)。

typedef int64_t (AdInfo::*field_func)(void) const;
static field_func get_field_func(int field_type) {
    switch(field_type) {
        case 1:
            return &AdInfo::id1;
        case 2:
            return &AdInfo::id2;
        case 3:
            return &AdInfo::id3;
        default:
            return nullptr;
    }
}
 
auto selected_func = get_field_func(field_type);
if (selected_func != nullptr) {
    for (const auto& ad_info : ad_info_list) {
        auto val = (ad_info.*selected_func)();
        // ...
    }
}

4. 利用AVX指令集進(jìn)行并行計(jì)算，下面是一個(gè)使用AVX256指令集計(jì)算兩個(gè)“std::vector”向量的點(diǎn)積的代碼示例，首先使用“_mm256_mul_ps“函數(shù)和“_mm256_add_ps”函數(shù)完成了浮點(diǎn)數(shù)的相乘和累加，然后通過“_mm256_hadd_ps”函數(shù)得到計(jì)算結(jié)果，最后處理不能被8整除的部分。

float dot_product_avx256(const std::vector<float>& vec1, const std::vector<float>& vec2) {
    if (vec1.size() != vec2.size()) {
        return 0;
    }
    size_t vec_size = vec1.size();
    size_t block_width = 8;
    size_t loop_cnt = vec_size / block_width;
    size_t remainder = vec_size % block_width;
 
    __m256 sum = _mm256_setzero_ps();
    for (size_t i = 0; i < loop_cnt * block_width; i += block_width) {
        __m256 a = _mm256_loadu_ps(&vec1[i]);
        __m256 b = _mm256_loadu_ps(&vec2[i]);
        __m256 c = _mm256_mul_ps(a, b);
        sum = _mm256_add_ps(sum, c);
    }
    __m256 hsum = _mm256_hadd_ps(sum, sum);
    __m256 hsum2 = _mm256_hadd_ps(hsum, hsum);
    float result[8];
    _mm256_storeu_ps(result, hsum2);
    float dot = result[0] + result[4];
 
    for (size_t i = loop_cnt * block_width; i < vec_size; ++i) {
        dot += vec1[i] * vec2[i];
    }
 
    return dot;
}

對(duì)于在線服務(wù)的性能優(yōu)化是一件細(xì)致且瑣碎的工作，上述的優(yōu)化手段及實(shí)踐僅是一小部分，更多繁復(fù)的細(xì)節(jié)不再贅述。針對(duì)不同的業(yè)務(wù)場(chǎng)景，性能優(yōu)化是否最終有效還需要更全面的測(cè)試才能得到驗(yàn)證。通過“觀測(cè)、定位、優(yōu)化、測(cè)試”這樣的正向循環(huán)，在經(jīng)過持續(xù)一年的性能優(yōu)化后，推理服務(wù)的CPU開銷相對(duì)降低了21%，同時(shí)峰值的吞吐量提高了13%。

內(nèi)存治理

在內(nèi)存治理方面，常見的優(yōu)化手段主要圍繞著數(shù)據(jù)格式的設(shè)計(jì)與升級(jí)，而此處筆者想分享的，是關(guān)于服務(wù)運(yùn)行時(shí)的內(nèi)存治理。具體到實(shí)際工作中，效果廣告引擎中的多數(shù)在線服務(wù)，都是基于BRPC框架開發(fā)的C++服務(wù)，通過SessionData對(duì)象來管理一次請(qǐng)求中的數(shù)據(jù)。

在筆者目前使用的版本中，BRPC框架可以通過在服務(wù)啟動(dòng)時(shí)預(yù)生成若干個(gè)SessionData對(duì)象來響應(yīng)請(qǐng)求，當(dāng)某個(gè)SessionData對(duì)象完成一次響應(yīng)后，會(huì)清理其中保存的數(shù)據(jù)以等待下一個(gè)請(qǐng)求調(diào)用。當(dāng)SessionData對(duì)象中需要存儲(chǔ)的成員變量過多時(shí)，就會(huì)產(chǎn)生頻繁的內(nèi)存申請(qǐng)和釋放，同時(shí)容易導(dǎo)致內(nèi)存碎片化。為了解決這個(gè)問題，我們對(duì)SessionData中的數(shù)據(jù)進(jìn)行了預(yù)分配和池化處理，當(dāng)SessionData創(chuàng)建時(shí)就對(duì)其進(jìn)行了初始化，一次性分配了所需的內(nèi)存，并且在清理數(shù)據(jù)時(shí)僅重置數(shù)據(jù)而不進(jìn)行銷毀操作。

此外，SessionData對(duì)象本身也是通過一個(gè)對(duì)象池進(jìn)行管理的，當(dāng)請(qǐng)求到達(dá)時(shí)會(huì)從對(duì)象池中獲取一個(gè)SessionData對(duì)象來處理請(qǐng)求，當(dāng)請(qǐng)求處理完成后歸還至對(duì)象池中。若在線服務(wù)的訪問量突然增加，或者服務(wù)處理時(shí)間突然變長(zhǎng)時(shí)，將會(huì)導(dǎo)致對(duì)象池中沒有可用的SessionData對(duì)象。此時(shí)，對(duì)象池會(huì)創(chuàng)建并初始化新的SessionData對(duì)象以響應(yīng)后續(xù)請(qǐng)求。然而，當(dāng)服務(wù)恢復(fù)平穩(wěn)之后，這些新創(chuàng)建出的SessionData對(duì)象就會(huì)處于閑置狀態(tài)，不會(huì)被主動(dòng)回收釋放，這就導(dǎo)致了運(yùn)行時(shí)內(nèi)存的增加。為了解決這個(gè)問題，通過BRPC框架中的hook函數(shù)，實(shí)現(xiàn)了SessionData對(duì)象的回收機(jī)制。需要注意的是，回收SessionData對(duì)象時(shí)會(huì)釋放一部分內(nèi)存，如果同時(shí)進(jìn)行大量的回收操作，會(huì)導(dǎo)致服務(wù)性能的抖動(dòng)，因此設(shè)計(jì)了一個(gè)較為平滑的回收方案。當(dāng)服務(wù)檢測(cè)到目前對(duì)象池的空閑對(duì)象數(shù)量大于設(shè)定時(shí)，會(huì)按一定概率對(duì)多余的SessionData對(duì)象進(jìn)行回收，在保證服務(wù)的穩(wěn)定性和彈性的同時(shí)，也有效降低了服務(wù)運(yùn)行時(shí)的內(nèi)存開銷。根據(jù)SessionData對(duì)象在服務(wù)中的定義及內(nèi)存占比不同，在線服務(wù)的運(yùn)行時(shí)內(nèi)存開銷下降了約15%～22%左右。

網(wǎng)絡(luò)IO

在網(wǎng)絡(luò)IO方面，已經(jīng)通過采用Protobuf作為服務(wù)間的傳輸格式來降低數(shù)據(jù)的傳輸量，然而對(duì)于一些特殊場(chǎng)景而言，直接使用原生的數(shù)據(jù)格式可能并不是最優(yōu)解。

例如，推理服務(wù)以容器化的方式部署在物理機(jī)上，服務(wù)需要加載多個(gè)模型數(shù)據(jù)以及用于進(jìn)行特征計(jì)算的正排詞表數(shù)據(jù)，當(dāng)內(nèi)存占用較大時(shí)會(huì)使用多個(gè)節(jié)點(diǎn)的NUMA節(jié)點(diǎn)內(nèi)存，當(dāng)出現(xiàn)訪問遠(yuǎn)端節(jié)點(diǎn)的內(nèi)存時(shí)會(huì)導(dǎo)致一定的內(nèi)存延遲增加。由于推理服務(wù)是一個(gè)計(jì)算密集型的服務(wù)，在負(fù)載較高時(shí)帶寬競(jìng)爭(zhēng)的情況會(huì)更為明顯，內(nèi)存延遲可能會(huì)導(dǎo)致服務(wù)的響應(yīng)時(shí)間顯著升高，嚴(yán)重情況下可能會(huì)導(dǎo)致服務(wù)不可用。

為了解決這類問題，同時(shí)進(jìn)一步對(duì)服務(wù)架構(gòu)進(jìn)行解耦，計(jì)劃將推理服務(wù)中的模型計(jì)算模塊單獨(dú)進(jìn)行服務(wù)化改造，同時(shí)該服務(wù)僅需要加載少量模型數(shù)據(jù)，將內(nèi)存用量限制在單個(gè)NUMA節(jié)點(diǎn)所管理的內(nèi)存空間內(nèi)，通過將進(jìn)程進(jìn)行NUMA節(jié)點(diǎn)綁定的部署方式避免了跨節(jié)點(diǎn)訪問內(nèi)存。

在這個(gè)設(shè)計(jì)方案中，推理服務(wù)需要在特征計(jì)算后，將每個(gè)廣告創(chuàng)意得到的特征簽名數(shù)組（通常為uint64數(shù)組）發(fā)送給模型計(jì)算服務(wù)。最直觀的數(shù)據(jù)傳輸方案是為每一個(gè)待處理的廣告創(chuàng)意定義一個(gè)uint64數(shù)組來傳輸特征簽名數(shù)組，這里有個(gè)問題就是每個(gè)uint64數(shù)組都會(huì)添加一些額外的數(shù)據(jù)信息，導(dǎo)致消息體變大。并且由于每個(gè)特征簽名都是經(jīng)過哈希計(jì)算后的數(shù)值較大的uint64，因此Protobuf內(nèi)置的變長(zhǎng)算法并不能起到壓縮數(shù)據(jù)的作用。

// 原版（未使用）
message Input {
    repeated uint64 value = 1 [packed = true];
}
message Request {
    repeated Input inputs = 1;
}

改進(jìn)后的設(shè)計(jì)，是將所有廣告創(chuàng)意放在同一個(gè)uint64數(shù)組中，并且新增一個(gè)uint32數(shù)組來記錄每個(gè)廣告創(chuàng)意對(duì)應(yīng)的特征簽名下標(biāo)。使用兩個(gè)大數(shù)組的方式降低了數(shù)據(jù)傳輸開銷。

// 改進(jìn)I
message Request {
    repeated uint32 index = 1 [packed = true];
    repeated uint64 value = 2 [packed = true];
}

由于在同一批請(qǐng)求中，包含了許多公共的特征簽名，主要是來自用戶側(cè)的特征數(shù)據(jù)，因此可以提取出公共的部分，以減少value中的重復(fù)數(shù)據(jù)。相較于“改進(jìn)I”，實(shí)測(cè)網(wǎng)絡(luò)傳輸?shù)膸捪陆盗?0%。

// 改進(jìn)II
message Request {
    repeated uint32 index = 1 [packed = true];
    repeated uint64 value = 2 [packed = true];
    repeated uint64 shared = 3 [packed = true];
}

在“改進(jìn)II”方案上取得的收益，主要來自于用戶側(cè)特征簽名占整體比例的多少，隨著將來模型的迭代升級(jí)，這個(gè)比例的變化情況會(huì)難以預(yù)估，并且篩選公共特征簽名的過程也帶來了不少的性能開銷。最終的數(shù)據(jù)傳輸方案采用倒排索引的方式，對(duì)同一批次的特征簽名和廣告創(chuàng)意創(chuàng)建一個(gè)倒排索引。

// 改進(jìn)III
message Inverted {
    repeated uint64 key = 1 [packed = true];
    repeated uint32 index = 2 [packed = true];
    repeated uint32 value = 3 [packed = true];
    repeated uint32 length = 4 [packed = true];
}
message Request {
    Inverted inverted = 1;
}

在“改進(jìn)III”方案中，key字段用來存儲(chǔ)所有的特征簽名，index字段記錄了每個(gè)特征簽名對(duì)應(yīng)在value數(shù)組中的起始和終止下標(biāo)，value字段則記錄了該特征簽名所對(duì)應(yīng)的廣告創(chuàng)意下標(biāo)。這個(gè)方案的優(yōu)點(diǎn)是所有特征簽名數(shù)據(jù)僅記錄一次，最大限度減少了不可壓縮的uint64的數(shù)據(jù)量，index和value字段的數(shù)值大小十分有限，在實(shí)際場(chǎng)景中都可以通過變長(zhǎng)壓縮的方式進(jìn)行大幅壓縮，同時(shí)使用了packed標(biāo)志，進(jìn)一步減少了元數(shù)據(jù)帶來的開銷。為了后續(xù)重建每個(gè)廣告創(chuàng)意的特征簽名列表時(shí)的性能考慮，額外定義了length字段來存儲(chǔ)每個(gè)廣告創(chuàng)意的特征簽名列表長(zhǎng)度。即使在額外增加length信息之后，相較于“改進(jìn)II”方案，該方案進(jìn)一步將網(wǎng)絡(luò)傳輸?shù)膸捪陆盗?0%，同時(shí)由于構(gòu)建請(qǐng)求的計(jì)算復(fù)雜度下降，構(gòu)建請(qǐng)求的模塊耗時(shí)也降低了14%，在降低網(wǎng)絡(luò)IO的同時(shí)，也降低了CPU算力開銷。

五、思考與展望

在保障業(yè)務(wù)持續(xù)迭代的同時(shí)，通過對(duì)在線服務(wù)進(jìn)行多輪不斷的升級(jí)和優(yōu)化，服務(wù)性能有了顯著提升，其中CPU、內(nèi)存、網(wǎng)絡(luò)IO等資源的使用效率得到了明顯改善，在線集群整體節(jié)省了上萬核的CPU算力。在此過程中，研發(fā)團(tuán)隊(duì)也積累了豐富的經(jīng)驗(yàn)和知識(shí)，將為未來的項(xiàng)目研發(fā)提供了重要支持。

性能優(yōu)化是一個(gè)持續(xù)的過程，它要求我們的研發(fā)人員在業(yè)務(wù)發(fā)展和技術(shù)更新的過程中不斷發(fā)現(xiàn)問題、探索解決方案，并持續(xù)進(jìn)行精細(xì)化調(diào)整。這不僅僅是一個(gè)單次任務(wù)，而是一個(gè)長(zhǎng)期的、不斷打磨和優(yōu)化的過程，旨在尋找既實(shí)用又高效的優(yōu)化策略。更為關(guān)鍵的是，性能優(yōu)化往往不是孤立的任務(wù)，而是需要跨服務(wù)、跨團(tuán)隊(duì)的協(xié)作，這要求項(xiàng)目主導(dǎo)方需要全面考慮系統(tǒng)的負(fù)載和收益，協(xié)同各方共同推進(jìn)優(yōu)化方案的實(shí)施，實(shí)現(xiàn)真正的效益最大化。

在編寫本文的過程中，由于文章篇幅限制以及個(gè)人工作經(jīng)驗(yàn)的局限，筆者僅能分享在線推理服務(wù)性能優(yōu)化方面的部分心得和成果。在此，要感謝所有在工作項(xiàng)目中給予幫助和支持的公司及團(tuán)隊(duì)成員。本文旨在為從事相關(guān)領(lǐng)域的讀者提供一些啟發(fā)，尤其希望能對(duì)面臨類似性能挑戰(zhàn)的研發(fā)人員帶來靈感和實(shí)際收獲。

本期作者

李淵馳嗶哩嗶哩資深開發(fā)工程師