KamoCRM

हर अनुरोध पर पूरे कैटलॉग को फिर से विलय करना बंद करें

Performancekamo-internal
शिप
26 अगस्त 2026 को 2:30 am बजे UTC
लेखक
kamo
करना
c36c532

getRequestConfig प्रति अनुरोध चलाता है, और किसी भी गैर-अंग्रेजी सदस्य के लिए इसे बुलाया जाता है हर बार पूरे 23,252-key कैटलॉग पर विलय के साथ - परिणाम का पुनर्निर्माण वह अगली तैनाती तक नहीं बदल सकता। डेस्कटॉप CPU पर मापा गया: 8-25 ms स्थानीय लोगों पर, औसतन ~16 ms, एकल-थ्रेडेडेड काम के सामने बैठे प्रतिक्रिया। एक फली डेस्कटॉप की तुलना में धीमी है, और यह हर पेज लोड के लिए TTFB पर उतरता है प्रत्येक सदस्य जो अंग्रेजी पढ़ नहीं रहा है। प्रक्रिया के जीवन के लिए प्रति स्थानीय कैश्ड। अंग्रेजी पथ अछूता है - यह पहले से ही बिना विलय के आधार सूची वापस लौटे। दो चीजें इस बात से सस्ता बनाती हैं। यह निर्माण द्वारा बाध्य है: isLocale() इससे पहले कि यह मानचित्र तक पहुंच जाए, इसलिए प्रति समर्थित एक प्रविष्टि पर निर्भर है स्थानीय, उनमें से 21। और एक कैश्ड कैटलॉग ज्यादातर मुफ्त है - mergeWithFallback प्रतियां स्ट्रिंग के बजाय स्ट्रिंग REFERENCES, तो क्या बनाए रखा है पर एक वस्तु रीढ़ है आयात कैश पहले से ही रखती है। छह विलय प्रतियों से अलग नहीं थे अलग प्रक्रियाओं में एक हेप माप में शून्य। एक लापता स्थानीय फ़ाइल के लिए अंग्रेजी गिरावट को जानबूझकर कैश किया जाता है। स्थानीय फ़ाइल छवि के अंदर जहाज इतना है कि पहले अनुरोध पर अनुपस्थित है के लिए अनुपस्थित है प्रक्रिया का पूरा जीवन; प्रति अनुरोध पर असफलता को फिर से पढ़ना कुछ नहीं खरीदा। साझा करने के लिए सुरक्षित क्योंकि यह कुछ भी नहीं है: getMessages() का एकमात्र उपभोक्ता है app/layout.tsx, जो इसे पढ़ता है और इसे NextIntlClientProvider पर हाथ देता है। सत्यापित: tsc -noEmit i18n/और app/layout.tsx पर उनके पृथक आयात के साथ स्वच्छ।.

सभी बदलाव

जैसा कि आप शिपिंग देखते हैं?

यह सब अपने कार्यक्षेत्र में आता है। मुफ्त योजना शुरू करें और इस पृष्ठ को एक महीने में फिर से पढ़ें।.

Foreverमूल्य निर्धारण देखें