- JavaScript और Node.js वातावरण में validation लाइब्रेरी Joi, दूसरी लाइब्रेरीज़ की तुलना में performance में धीमी है
- Joi को किसी दूसरी लाइब्रेरी से बदलने पर बैकएंड वातावरण में performance सुधार की उम्मीद की जा सकती है
- यह टेस्ट किया गया कि क्या बैकएंड एप्लिकेशन में सार्थक performance अंतर दिखाई दे सकता है
- k6 का उपयोग करके टेस्ट किया गया, और lodash तथा class-transformer को भी साथ में परखा गया
- performance टेस्ट के नतीजे:
- native vs lodash: performance में कोई अंतर नहीं
- object literal vs class-transformer: performance में कोई अंतर नहीं
- non-validation vs Joi: Joi के धीमे performance के बावजूद performance में कोई अंतर दिखाई नहीं दिया
- performance महत्वपूर्ण है, लेकिन पहले से चल रहे प्रोजेक्ट में बदलाव करने पर लगाए गए समय की तुलना में performance अंतर महसूस नहीं हो सकता
8 टिप्पणियां
मुझे लगता है कि लेखक का मकसद bottleneck स्थिति को सुधारना नहीं, बल्कि यह कहना है कि वास्तविक परिस्थिति से मिलते-जुलते माहौल में validation library के performance का अंतर बहुत ज़्यादा मायने नहीं रखता।
अगर मान लें कि यह वैसी service नहीं है जिसमें केवल वही io bound task हों जिनकी व्याख्या मुख्य लेख में की गई है, बल्कि यह एक cpu bound task service है, तो क्या होगा?
वास्तविक environment की services सोच से कहीं ज़्यादा complex होती हैं। UI रेंडर करने के लिए ज़रूरी data serving API ही server का एकमात्र काम नहीं होता।
Validation और JSON serialization का काम main thread पर होने वाली computation है, इसलिए इसे हल्के में नहीं लिया जा सकता। TS backend इकोसिस्टम में सबसे आम तौर पर
class-validator/class-transformerका इस्तेमाल होता है। और इसकी प्रति सेकंड validation capacity लगभग 4MB है, यानी main thread पर प्रति सेकंड 4MB से ज़्यादा प्रोसेस नहीं किया जा सकता।जहाँ तक DB I/O का सवाल है, वह main नहीं बल्कि background thread पर चलता है, इसलिए backend server के नज़रिए से (TS server के नज़रिए से) इसका concurrent connections पर बहुत बड़ा असर नहीं पड़ता। लेकिन service की प्रकृति के अनुसार अगर एक बार में भेजे जाने वाले DTO का आकार बड़ा हो, तो धीमी validation कहीं ज़्यादा डरावनी हो सकती है (वास्तव में बड़े per-request data वाले service बनाते समय NestJS में concurrent connections single digit तक रह जाने का मामला भी था)।
मैं सहमत हूँ। लेखक जिस "वास्तविक परिस्थितियों में" होने का दावा कर रहे हैं, उसके लिए उदाहरण के तौर पर दी गई वास्तविक स्थिति बहुत ज़्यादा संकीर्ण है।
ऊपर वाले व्यक्ति की बात की तरह, यह समझना मुश्किल है कि इसमें DB input/output क्यों शामिल किया गया है। और धीमा validation तथा serialization, request DTO की तुलना में response DTO में server performance को कहीं ज़्यादा नुकसान पहुँचाते हैं। आखिर में, इस तरह के benchmark experiment करते समय केवल एक DTO रखकर नहीं, बल्कि कई तरह के DTO के साथ प्रयोग करना चाहिए.
वास्तव में, जब DB I/O नहीं होता और अलग-अलग संरचना वाले DTO पर प्रयोग किए जाते हैं, तो उनके नतीजे अलग आते हैं।
शुरुआत से ही लगता है कि bottleneck db connection वाली तरफ है, तो क्या विषय ही गलत चुना गया है?
ऐसा लगता है मानो इसे इस तरह पेश किया गया है कि जैसे performance improvement नहीं है फिर भी है, लेकिन असल में शुरू से ही bottleneck DB side पर है, इसलिए bottleneck न होने वाले हिस्से को बेहतर बनाने पर केंद्रित यह लेखन गलतफहमी पैदा कर सकता है।
ज़्यादातर environments में performance improvement का मतलब bottleneck points को दूर करना होता है। Validation को optimize करते समय पहले यह पहचान लिया जाना चाहिए कि bottleneck validation वाली तरफ ही है।