盧偉冰長文解析K60至尊版 對Redmi有著里程碑式的意義
在今天的Redmi后性能時代戰(zhàn)略發(fā)布會結(jié)束之后，Redmi總經(jīng)理盧偉冰又帶來了一篇長文，詳解了為什么 Redmi 要開啟后性能時代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
作為國內(nèi)領(lǐng)先的在線視頻平臺，嗶哩嗶哩（以下簡稱“B站”）正經(jīng)歷著業(yè)務(wù)體量和用戶規(guī)模的快速增長。隨著訪問量的持續(xù)增長和業(yè)務(wù)復雜程度的增加，在相對有限的服務(wù)器資源下如何優(yōu)化在線服務(wù)性能和提高資源利用率，成為了工程研發(fā)團隊面臨的重要挑戰(zhàn)之一。
本文將以筆者所在的商業(yè)技術(shù)中心為例，重點討論效果廣告引擎的在線推理部分。文章將分享筆者在實際工作中遇到的挑戰(zhàn)及相應(yīng)的優(yōu)化方案。首先，將介紹項目背景和當前系統(tǒng)的運行狀況；接著，將詳細探討性能指標量化、服務(wù)調(diào)用、CPU計算、內(nèi)存治理及網(wǎng)絡(luò)IO等方面的優(yōu)化策略；最后，將總結(jié)對性能優(yōu)化的一些思考，并展望未來性能優(yōu)化的方向。本文的目的是回顧并總結(jié)當前在線服務(wù)性能優(yōu)化的工作，同時也希望這些經(jīng)驗?zāi)転槠渌邪l(fā)人員在處理類似問題時提供參考和啟發(fā)。
筆者所在的團隊主要負責在線效果廣告引擎的研發(fā)工作，該服務(wù)作為商業(yè)化系統(tǒng)的重要組成之一，為公司帶來了實質(zhì)性的商業(yè)貢獻。通過精準高效的廣告投放，能夠為公司帶來穩(wěn)定且可觀的廣告收入，成為支撐平臺發(fā)展的關(guān)鍵營收來源之一，進一步支持了平臺的內(nèi)容創(chuàng)新和技術(shù)研發(fā)，構(gòu)成良性循環(huán)。對于廣告主而言，效果廣告引擎提供了精準定向用戶的能力，顯著提升了廣告?zhèn)鞑サ男Ч瑸槠鋷砀叩膹V告轉(zhuǎn)化和投資回報。對于用戶而言，通過更貼近用戶行為習慣的廣告投放，確保了廣告內(nèi)容與用戶興趣和需求的高度匹配，最大限度地保障了用戶體驗。
隨著效果廣告業(yè)務(wù)的快速發(fā)展，處理的業(yè)務(wù)復雜度不斷提升，對在線服務(wù)的處理效率和吞吐量提出了更高要求。同時，B站的用戶規(guī)模和使用時長的持續(xù)增長也加大了這一挑戰(zhàn)。以在線推理服務(wù)為例，它需要對廣告創(chuàng)意候選集進行一系列預估打分，主要包括特征計算和模型計算兩個環(huán)節(jié)。特征處理階段涉及用戶和廣告數(shù)據(jù)的提取、過濾、拼接等操作，隨著特征數(shù)據(jù)的深入挖掘和應(yīng)用，所需要處理的數(shù)據(jù)量也在不斷增加。在模型計算階段，支持的模型類型從LR、FM模型逐漸升級到DNN模型，增強了模型的表達能力，但同時也加大了算力資源的消耗。類似的資源開銷增長問題也存在于效果廣告引擎的其他服務(wù)中。因此，工程研發(fā)團隊面臨的挑戰(zhàn)在于如何有效地對效果廣告引擎進行性能優(yōu)化，確保在硬件資源相對有限的情況下，依然能夠支持并促進業(yè)務(wù)的持續(xù)增長。
首先需要介紹一下效果廣告引擎的系統(tǒng)構(gòu)成，主要包含了以下幾個服務(wù)：
檢索引擎：作為廣告業(yè)務(wù)的入口，接受來自各個調(diào)用方的請求，并且會對流量進行預處理，其中包括對流量進行實驗分組和標記。
效果廣告檢索服務(wù)：作為效果廣告的業(yè)務(wù)核心，負責對候選集中的廣告創(chuàng)意進行優(yōu)選，并且將勝選的結(jié)果回傳給檢索引擎。
召回/粗排服務(wù)：根據(jù)流量的上下文信息，從所有在投的廣告創(chuàng)意中挑選出一批符合條件的廣告創(chuàng)意，并且進行粗排打分，將最終的Top N作為候選集返回給效果廣告檢索服務(wù)。
推理服務(wù)：負責對候選集中的廣告創(chuàng)意進行一系列精排打分，將最終結(jié)果返回給效果廣告檢索服務(wù)。
此處需要說明的是，由于本文的重點是在線推理服務(wù)，因此對于廣告引擎中的其他部分進行了大幅簡化，實際的效果廣告引擎要更為復雜。為了進一步便于理解，使用下圖來說明簡化后的效果廣告引擎內(nèi)部各服務(wù)之間的調(diào)用關(guān)系及主要功能模塊：
圖1 效果廣告引擎調(diào)用關(guān)系及主要功能模塊
目前效果廣告引擎的在線集群規(guī)模已經(jīng)達到了數(shù)千臺服務(wù)器，其中在線推理服務(wù)的CPU資源占比約為整體的45%，召回/粗排服務(wù)占比約為21%，效果廣告檢索服務(wù)占比約為10%。通過CPU資源的分配比例，可以直觀反映出各服務(wù)之間計算復雜度的差異，同時也揭示了系統(tǒng)中存在的潛在性能瓶頸。推理服務(wù)作為系統(tǒng)資源開銷最大的在線服務(wù)，對其進行性能優(yōu)化的收益也是最為顯著的。
在對效果廣告引擎的背景及現(xiàn)狀有了初步的了解之后，下面本文將針對推理服務(wù)的各項優(yōu)化手段進行更為詳細的介紹。
在實際工作中，對于在線服務(wù)的性能優(yōu)化首先要建立在性能度量的基礎(chǔ)上，因此在開始優(yōu)化之前，需要對在線服務(wù)的各項數(shù)據(jù)指標進行可量化的測量和分析。
從宏觀角度來看，可以通過埋點的方式對在線服務(wù)的各個模塊耗時進行監(jiān)控和分析，定位到耗時較高的模塊。之后，可以通過更細粒度的埋點或者日志，來找到開銷較高的操作，并進行性能優(yōu)化。同時作為在線服務(wù)，效果廣告引擎的各服務(wù)之間的調(diào)用耗時也是需要監(jiān)控的。受益于服務(wù)使用的BRPC框架，效果廣告引擎的子服務(wù)都實現(xiàn)了較為完善的監(jiān)控指標，包括各模塊之間的平均耗時、中位數(shù)耗時、97線耗時等，并且對于各類遠程調(diào)用也都有對應(yīng)的耗時監(jiān)控指標。依靠這些能夠被量化的數(shù)據(jù)，我們能夠快速定位到哪些模塊和調(diào)用的耗時較高，并且能夠在開發(fā)人力有限的情況下，給出性能優(yōu)化的先后順序，盡可能提高單次性能優(yōu)化的收益。需要特別注意的是，在確保性能指標不失真的前提下，可以對性能指標的收集和上報進行一定程度的采樣操作，主要是為了防止性能度量本身給服務(wù)帶來過大的額外算力開銷。
在得到較為完善的性能指標之后，就可以結(jié)合對于推理服務(wù)的業(yè)務(wù)理解，從業(yè)務(wù)流程和服務(wù)調(diào)用的角度對在線服務(wù)進行全局分析。這部分的優(yōu)化思路主要是在處理一次用戶請求的過程中，減少數(shù)據(jù)的重復計算，并且降低數(shù)據(jù)傳輸?shù)某杀尽?span style="display:none">K7y28資訊網(wǎng)——每日最新資訊28at.com
在較早的設(shè)計中，效果廣告檢索服務(wù)會將候選集中的廣告創(chuàng)意拆分成多個推理請求，并行發(fā)送給多個推理服務(wù)節(jié)點，從而確保單個請求的處理耗時不會較高。如上文所述，推理服務(wù)需要獲取用戶側(cè)的數(shù)據(jù)來進行特征處理，這些數(shù)據(jù)存放在Redis集群中。因此在處理每一個推理請求時，推理服務(wù)都需要單獨訪問一次Redis來獲取用戶數(shù)據(jù)，造成了Redis服務(wù)端訪問較多，并且數(shù)據(jù)重復傳輸?shù)膯栴}。通過將訪問Redis的操作上移至廣告檢索服務(wù)，然后再發(fā)送給推理服務(wù)的方式，有效減少了對Redis服務(wù)的訪問量，降低了Redis服務(wù)端的算力開銷和網(wǎng)絡(luò)IO開銷。
此外，在對早期方案重構(gòu)的過程中，我們對服務(wù)調(diào)用之間所使用的數(shù)據(jù)格式也進行了升級，將原本類似JSON的數(shù)據(jù)處理方式，升級成了基于Protobuf3的數(shù)據(jù)處理方式。相比于文本格式的JSON，PB編碼的數(shù)據(jù)通常更小，并且擁有更快的序列化和反序列化速度，這在處理大量數(shù)據(jù)時尤其重要。同時，將推理請求中的字段類型與特征計算中所需要的數(shù)據(jù)類型進行對齊，減少了大量的字符串轉(zhuǎn)化及數(shù)據(jù)校驗操作，降低了CPU算力開銷。
這一類問題看似比較基礎(chǔ)，但是在早期引擎架構(gòu)快速迭代的過程中，由于不同階段的各種原因，導致各個服務(wù)之間的設(shè)計無法完全一致，一些細節(jié)問題是比較容易被忽略的。隨著業(yè)務(wù)的迭代和增長，這類小問題的影響就會被逐漸放大，導致服務(wù)性能下降和算力資源浪費。因此，定期對在線服務(wù)的業(yè)務(wù)和架構(gòu)進行梳理回顧，是保障服務(wù)健康穩(wěn)定的重要手段之一。
將視角聚焦到推理服務(wù)中，對于單次推理請求，我們同樣也可以使用減少數(shù)據(jù)重復計算的方式來降低CPU算力開銷，并且可以使用Perf性能分析工具，來進一步優(yōu)化熱點函數(shù)的算力開銷。
首先在進行特征計算的過程中，包含了對于用戶側(cè)特征和廣告?zhèn)忍卣鞯奶幚恚渲杏脩魝?cè)特征的計算結(jié)果是能夠被重復使用的。在推理服務(wù)的處理過程中，單次請求中的多個廣告創(chuàng)意，會使用多線程并行的方式進行處理，此時會先將用戶側(cè)數(shù)據(jù)與單個廣告創(chuàng)意進行計算，將結(jié)果存儲在特征計算的運行時對象中，并且通過標記來區(qū)分用戶側(cè)特征和廣告?zhèn)忍卣鳌Ｈ缓螅瑢⑵渲械挠脩魝?cè)特征計算結(jié)果復制到其他線程的運行時對象中，再啟動線程進行并行計算。這樣既可以使用多線程來提高批量廣告的特征計算處理速度，又不會因為重復計算用戶側(cè)數(shù)據(jù)而造成額外的算力開銷。
進一步的，通過使用Perf性能分析工具，可以觀察到具體某段代碼的執(zhí)行效率，并且分析出主要的性能開銷點。在實際工作中，由于推理服務(wù)本身的迭代較為頻繁，我們會定期對服務(wù)性能進行評估和回顧。當發(fā)現(xiàn)存在性能熱點時，會優(yōu)先進行性能優(yōu)化，常見的代碼優(yōu)化手段有：
針對這些優(yōu)化手段，下面筆者會提供一些實際工作中遇到的具體事例以作參考。
1. 使用__builtin_expect內(nèi)建函數(shù)來提供分支預測的提示，該函數(shù)會給GCC編譯器提示，告知其某個條件判斷的結(jié)果更可能是true還是false，通常用于優(yōu)化代碼中高度可能或者不可能執(zhí)行的分支。在實際編寫代碼的過程中，該函數(shù)通常與宏一起使用，包括Linux在內(nèi)的各種代碼中都封裝了自己likely和unlikely宏來提高性能。
2. 使用循環(huán)展開來提高代碼性能，下面這段代碼是通過循環(huán)展開來優(yōu)化數(shù)據(jù)構(gòu)建的例子，需要注意的是，當批量處理完展開部分的循環(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ù)指針的方式來減少條件判斷，并且提高時間局部性，下面是一個簡化后的例子。這段代碼的目的是根據(jù)“field_type”獲取“AdInfo”類中對應(yīng)的成員函數(shù)指針，并且在一個循環(huán)中對“ad_info_list”集合中的每一個“AdInfo”對象調(diào)用這個成員函數(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指令集進行并行計算，下面是一個使用AVX256指令集計算兩個“std::vector”向量的點積的代碼示例，首先使用“_mm256_mul_ps“函數(shù)和“_mm256_add_ps”函數(shù)完成了浮點數(shù)的相乘和累加，然后通過“_mm256_hadd_ps”函數(shù)得到計算結(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;}對于在線服務(wù)的性能優(yōu)化是一件細致且瑣碎的工作，上述的優(yōu)化手段及實踐僅是一小部分，更多繁復的細節(jié)不再贅述。針對不同的業(yè)務(wù)場景，性能優(yōu)化是否最終有效還需要更全面的測試才能得到驗證。通過“觀測、定位、優(yōu)化、測試”這樣的正向循環(huán)，在經(jīng)過持續(xù)一年的性能優(yōu)化后，推理服務(wù)的CPU開銷相對降低了21%，同時峰值的吞吐量提高了13%。
在內(nèi)存治理方面，常見的優(yōu)化手段主要圍繞著數(shù)據(jù)格式的設(shè)計與升級，而此處筆者想分享的，是關(guān)于服務(wù)運行時的內(nèi)存治理。具體到實際工作中，效果廣告引擎中的多數(shù)在線服務(wù)，都是基于BRPC框架開發(fā)的C++服務(wù)，通過SessionData對象來管理一次請求中的數(shù)據(jù)。
在筆者目前使用的版本中，BRPC框架可以通過在服務(wù)啟動時預生成若干個SessionData對象來響應(yīng)請求，當某個SessionData對象完成一次響應(yīng)后，會清理其中保存的數(shù)據(jù)以等待下一個請求調(diào)用。當SessionData對象中需要存儲的成員變量過多時，就會產(chǎn)生頻繁的內(nèi)存申請和釋放，同時容易導致內(nèi)存碎片化。為了解決這個問題，我們對SessionData中的數(shù)據(jù)進行了預分配和池化處理，當SessionData創(chuàng)建時就對其進行了初始化，一次性分配了所需的內(nèi)存，并且在清理數(shù)據(jù)時僅重置數(shù)據(jù)而不進行銷毀操作。
此外，SessionData對象本身也是通過一個對象池進行管理的，當請求到達時會從對象池中獲取一個SessionData對象來處理請求，當請求處理完成后歸還至對象池中。若在線服務(wù)的訪問量突然增加，或者服務(wù)處理時間突然變長時，將會導致對象池中沒有可用的SessionData對象。此時，對象池會創(chuàng)建并初始化新的SessionData對象以響應(yīng)后續(xù)請求。然而，當服務(wù)恢復平穩(wěn)之后，這些新創(chuàng)建出的SessionData對象就會處于閑置狀態(tài)，不會被主動回收釋放，這就導致了運行時內(nèi)存的增加。為了解決這個問題，通過BRPC框架中的hook函數(shù)，實現(xiàn)了SessionData對象的回收機制。需要注意的是，回收SessionData對象時會釋放一部分內(nèi)存，如果同時進行大量的回收操作，會導致服務(wù)性能的抖動，因此設(shè)計了一個較為平滑的回收方案。當服務(wù)檢測到目前對象池的空閑對象數(shù)量大于設(shè)定時，會按一定概率對多余的SessionData對象進行回收，在保證服務(wù)的穩(wěn)定性和彈性的同時，也有效降低了服務(wù)運行時的內(nèi)存開銷。根據(jù)SessionData對象在服務(wù)中的定義及內(nèi)存占比不同，在線服務(wù)的運行時內(nèi)存開銷下降了約15%～22%左右。
在網(wǎng)絡(luò)IO方面，已經(jīng)通過采用Protobuf作為服務(wù)間的傳輸格式來降低數(shù)據(jù)的傳輸量，然而對于一些特殊場景而言，直接使用原生的數(shù)據(jù)格式可能并不是最優(yōu)解。
例如，推理服務(wù)以容器化的方式部署在物理機上，服務(wù)需要加載多個模型數(shù)據(jù)以及用于進行特征計算的正排詞表數(shù)據(jù)，當內(nèi)存占用較大時會使用多個節(jié)點的NUMA節(jié)點內(nèi)存，當出現(xiàn)訪問遠端節(jié)點的內(nèi)存時會導致一定的內(nèi)存延遲增加。由于推理服務(wù)是一個計算密集型的服務(wù)，在負載較高時帶寬競爭的情況會更為明顯，內(nèi)存延遲可能會導致服務(wù)的響應(yīng)時間顯著升高，嚴重情況下可能會導致服務(wù)不可用。
為了解決這類問題，同時進一步對服務(wù)架構(gòu)進行解耦，計劃將推理服務(wù)中的模型計算模塊單獨進行服務(wù)化改造，同時該服務(wù)僅需要加載少量模型數(shù)據(jù)，將內(nèi)存用量限制在單個NUMA節(jié)點所管理的內(nèi)存空間內(nèi)，通過將進程進行NUMA節(jié)點綁定的部署方式避免了跨節(jié)點訪問內(nèi)存。
在這個設(shè)計方案中，推理服務(wù)需要在特征計算后，將每個廣告創(chuàng)意得到的特征簽名數(shù)組（通常為uint64數(shù)組）發(fā)送給模型計算服務(wù)。最直觀的數(shù)據(jù)傳輸方案是為每一個待處理的廣告創(chuàng)意定義一個uint64數(shù)組來傳輸特征簽名數(shù)組，這里有個問題就是每個uint64數(shù)組都會添加一些額外的數(shù)據(jù)信息，導致消息體變大。并且由于每個特征簽名都是經(jīng)過哈希計算后的數(shù)值較大的uint64，因此Protobuf內(nèi)置的變長算法并不能起到壓縮數(shù)據(jù)的作用。
// 原版（未使用）message Input { repeated uint64 value = 1 [packed = true];}message Request { repeated Input inputs = 1;}改進后的設(shè)計，是將所有廣告創(chuàng)意放在同一個uint64數(shù)組中，并且新增一個uint32數(shù)組來記錄每個廣告創(chuàng)意對應(yīng)的特征簽名下標。使用兩個大數(shù)組的方式降低了數(shù)據(jù)傳輸開銷。
// 改進Imessage Request { repeated uint32 index = 1 [packed = true]; repeated uint64 value = 2 [packed = true];}由于在同一批請求中，包含了許多公共的特征簽名，主要是來自用戶側(cè)的特征數(shù)據(jù)，因此可以提取出公共的部分，以減少value中的重復數(shù)據(jù)。相較于“改進I”，實測網(wǎng)絡(luò)傳輸?shù)膸捪陆盗?0%。
// 改進IImessage Request { repeated uint32 index = 1 [packed = true]; repeated uint64 value = 2 [packed = true]; repeated uint64 shared = 3 [packed = true];}在“改進II”方案上取得的收益，主要來自于用戶側(cè)特征簽名占整體比例的多少，隨著將來模型的迭代升級，這個比例的變化情況會難以預估，并且篩選公共特征簽名的過程也帶來了不少的性能開銷。最終的數(shù)據(jù)傳輸方案采用倒排索引的方式，對同一批次的特征簽名和廣告創(chuàng)意創(chuàng)建一個倒排索引。
// 改進IIImessage 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;}在“改進III”方案中，key字段用來存儲所有的特征簽名，index字段記錄了每個特征簽名對應(yīng)在value數(shù)組中的起始和終止下標，value字段則記錄了該特征簽名所對應(yīng)的廣告創(chuàng)意下標。這個方案的優(yōu)點是所有特征簽名數(shù)據(jù)僅記錄一次，最大限度減少了不可壓縮的uint64的數(shù)據(jù)量，index和value字段的數(shù)值大小十分有限，在實際場景中都可以通過變長壓縮的方式進行大幅壓縮，同時使用了packed標志，進一步減少了元數(shù)據(jù)帶來的開銷。為了后續(xù)重建每個廣告創(chuàng)意的特征簽名列表時的性能考慮，額外定義了length字段來存儲每個廣告創(chuàng)意的特征簽名列表長度。即使在額外增加length信息之后，相較于“改進II”方案，該方案進一步將網(wǎng)絡(luò)傳輸?shù)膸捪陆盗?0%，同時由于構(gòu)建請求的計算復雜度下降，構(gòu)建請求的模塊耗時也降低了14%，在降低網(wǎng)絡(luò)IO的同時，也降低了CPU算力開銷。
在保障業(yè)務(wù)持續(xù)迭代的同時，通過對在線服務(wù)進行多輪不斷的升級和優(yōu)化，服務(wù)性能有了顯著提升，其中CPU、內(nèi)存、網(wǎng)絡(luò)IO等資源的使用效率得到了明顯改善，在線集群整體節(jié)省了上萬核的CPU算力。在此過程中，研發(fā)團隊也積累了豐富的經(jīng)驗和知識，將為未來的項目研發(fā)提供了重要支持。
性能優(yōu)化是一個持續(xù)的過程，它要求我們的研發(fā)人員在業(yè)務(wù)發(fā)展和技術(shù)更新的過程中不斷發(fā)現(xiàn)問題、探索解決方案，并持續(xù)進行精細化調(diào)整。這不僅僅是一個單次任務(wù)，而是一個長期的、不斷打磨和優(yōu)化的過程，旨在尋找既實用又高效的優(yōu)化策略。更為關(guān)鍵的是，性能優(yōu)化往往不是孤立的任務(wù)，而是需要跨服務(wù)、跨團隊的協(xié)作，這要求項目主導方需要全面考慮系統(tǒng)的負載和收益，協(xié)同各方共同推進優(yōu)化方案的實施，實現(xiàn)真正的效益最大化。
在編寫本文的過程中，由于文章篇幅限制以及個人工作經(jīng)驗的局限，筆者僅能分享在線推理服務(wù)性能優(yōu)化方面的部分心得和成果。在此，要感謝所有在工作項目中給予幫助和支持的公司及團隊成員。本文旨在為從事相關(guān)領(lǐng)域的讀者提供一些啟發(fā)，尤其希望能對面臨類似性能挑戰(zhàn)的研發(fā)人員帶來靈感和實際收獲。
本期作者
李淵馳嗶哩嗶哩資深開發(fā)工程師
本文鏈接：http://www.www897cc.com/showinfo-26-55191-0.html淺談B站效果廣告在線推理服務(wù)的性能優(yōu)化
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號