तकनीकी ऋण का शाश्वत मुद्दा

यह सबसे अच्छे प्रोजेक्ट राहत में से एक है। तस्वीर में - सभी उपयोगकर्ता अनुरोधों को संसाधित करने के लिए सीपीयू द्वारा खर्च किए गए कुल समय का एक ग्राफ। अंत में आप PHP 7.0 में संक्रमण देख सकते हैं। संस्करण 5.6 के बाद से। यह वर्ष 2016 है, 24 नवंबर को दोपहर में स्विच करना।

गणनाओं के दृष्टिकोण से, टूटू.ru मुख्य रूप से बिंदु ए से बिंदु बी तक एक टिकट खरीदने का अवसर है ऐसा करने के लिए, हम बड़ी संख्या में अनुसूचियों को पीसते हैं, कई एयरलाइन प्रणालियों की प्रतिक्रियाओं को कैश करते हैं और समय-समय पर डेटाबेस में अविश्वसनीय रूप से लंबे समय तक जुड़ने वाले प्रश्न बनाते हैं। सामान्य तौर पर, हम PHP में लिखे जाते हैं और हाल ही में जब तक हम पूरी तरह से उस पर थे (यदि भाषा सही ढंग से तैयार की गई है, तो आप इस पर वास्तविक समय प्रणाली भी बना सकते हैं)। हाल ही में, प्रदर्शन-महत्वपूर्ण क्षेत्रों को गो पर रिफैक्ट किया गया है।

हमारे पास लगातार एक तकनीकी ऋण है । और यह तेजी से होता है जितना हम चाहेंगे। अच्छी खबर: आपको यह सब कवर नहीं करना है। खराब: जैसा कि समर्थित कार्यक्षमता बढ़ती है, तकनीकी ऋण भी आनुपातिक रूप से बढ़ता है।

सामान्य तौर पर, तकनीकी ऋण निर्णय लेने में त्रुटि के लिए एक भुगतान है। आपने आर्किटेक्ट की तरह कुछ भी भविष्यवाणी नहीं की है, अर्थात, आपने एक पूर्वानुमान त्रुटि की है या अपर्याप्त जानकारी की शर्तों में निर्णय लिया है। कुछ बिंदु पर, आप समझते हैं कि आपको कोड (अक्सर आर्किटेक्चर स्तर पर) में कुछ बदलने की आवश्यकता है। फिर आप तुरंत बदल सकते हैं, लेकिन आप इंतजार कर सकते हैं। यदि आप प्रतीक्षा करते हैं - ब्याज तकनीक ऋण में भाग गया। इसलिए, समय-समय पर इसका पुनर्गठन करना अच्छा अभ्यास है। ठीक है, या अपने आप को दिवालिया घोषित करें और पूरे ब्लॉक को फिर से लिखें।

यह सब कैसे शुरू हुआ: अखंड और सामान्य कार्य

Tutu.ru परियोजना 2003 में उन समय की एक नियमित Runet वेबसाइट के रूप में शुरू हुई। यही है, यह एक डेटाबेस के बजाय फाइलों का एक गुच्छा था, HTML + JS के सामने एक PHP पेज। मेरे सहयोगी यूरी से कुछ उत्कृष्ट हैक थे, लेकिन वे किसी दिन उसे बेहतर बताएंगे। मैं 2006 में परियोजना में शामिल हुआ, पहले एक बाहरी सलाहकार के रूप में, जो सलाह और एक कोड दोनों के साथ मदद कर सकता था, और फिर, 2009 में, मैं एक तकनीकी निदेशक के रूप में राज्य में स्थानांतरित हो गया। सबसे पहले, हवाई टिकट की दिशा में चीजों को रखना आवश्यक था: यह वास्तुकला में सबसे अधिक भरा हुआ और सबसे जटिल हिस्सा था।

2006 में, मैं आपको याद दिलाता हूं, एक ट्रेन शेड्यूल था और ट्रेन टिकट खरीदने का अवसर था। हमने हवाई टिकट अनुभाग को एक अलग परियोजना के रूप में बनाने का फैसला किया, अर्थात यह सब केवल मोर्चे पर एकजुट था। सभी तीन परियोजनाओं (ट्रेन शेड्यूल, रेलवे और वायु) को अंततः अपने तरीके से लिखा गया था। उस समय, कोड हमें सामान्य लग रहा था, लेकिन कुछ हद तक अधूरा। Neperfektsionistskim। फिर वह बूढ़ा हो गया, खुद को बैसाखी के साथ कवर किया और रेलवे की दिशा में 2010 तक एक कद्दू में बदल गया।

रेलवे में, हमारे पास तकनीकी ऋण देने का समय नहीं था। Refactoring अवास्तविक थी: समस्याएं वास्तुकला में थीं। हमने हर चीज को फिर से गिराने और फिर से बनाने का फैसला किया, लेकिन एक लाइव प्रोजेक्ट पर भी यह मुश्किल था। नतीजतन, केवल पुराने URL को सामने छोड़ दिया गया था, और फिर ब्लॉक द्वारा ब्लॉक को फिर से लिखा गया था। एक आधार के रूप में, हमने विमानन क्षेत्र के विकास में एक साल पहले उपयोग किए गए दृष्टिकोणों को लिया।

PHP में फिर से लिखा। तब यह स्पष्ट था कि यह एकमात्र तरीका नहीं था, लेकिन हमारे लिए कोई उचित विकल्प नहीं थे। उन्होंने इसे चुना क्योंकि उनके पास पहले से ही अनुभव और उपलब्धियां थीं, यह स्पष्ट था कि वरिष्ठ डेवलपर्स के हाथों में यह एक अच्छी भाषा है। विकल्पों में से, C और C ++ बिलकुल उत्पादक थे, लेकिन उनमें से किसी भी पुनर्निर्माण या परिवर्तन ने फिर एक बुरा सपना बना दिया। ठीक है, याद नहीं। एक बुरे सपने थे।

एक उच्च-लोड परियोजना के दृष्टिकोण से एमएस और सभी .NET को भी नहीं माना गया था। तब लिनक्स पर आधारित के अलावा कोई विकल्प नहीं था। जावा एक अच्छा विकल्प है, लेकिन यह स्मृति से संसाधनों पर मांग कर रहा है, यह कनिष्ठ त्रुटियों को कभी भी माफ नहीं करता है और फिर यह जल्दी - अच्छी तरह से रिलीज जारी करने के लिए संभव नहीं था, या हम यह नहीं जानते थे। अब भी हम पायथन को केवल डेटा हेरफेर कार्यों के लिए बैकएंड के रूप में नहीं मानते हैं। जेएस - विशुद्ध रूप से सामने के नीचे। तब (और अब) रेल डेवलपर्स पर कोई रूबी नहीं थे। गो गया था। अभी भी पर्ल था, लेकिन विशेषज्ञों ने इसे वेब विकास के लिए अप्रमाणित माना, इसलिए उन्होंने इसे भी छोड़ दिया। PHP बची है।

अगली होली की कहानी PostgreSQL बनाम MySQL है। कहीं बेहतर, तो कहीं बेहतर। सामान्य तौर पर, तब यह चुनना अच्छा था कि क्या बेहतर निकला, इसलिए हमने MySQL और इसके कांटे चुने।

विकास का दृष्टिकोण अखंड था, फिर कोई अन्य दृष्टिकोण नहीं थे, लेकिन पुस्तकालयों के रूढ़िवादी ढांचे के साथ। ये आधुनिक एपीआई-केंद्रित दृष्टिकोण की शुरुआत हैं, जब प्रत्येक पुस्तकालय के बाहर एक मुखौटा होता है, जिसके लिए आप सीधे परियोजना के अन्य हिस्सों से कोड के अंदर खींच सकते हैं। लाइब्रेरीज़ को "परतों" में लिखा गया था जब प्रत्येक स्तर पर इनपुट का एक विशिष्ट प्रारूप होता है और कोड के आगे एक निश्चित प्रारूप पर गुजरता है, और यूनिट परीक्षण उनके बीच स्पिन करता है। यही है, परीक्षण-संचालित-विकास जैसा कुछ, लेकिन पिक्सेलयुक्त और डरावना।

यह सब कई सर्वरों पर होस्ट किया गया था, जिससे लोड के तहत स्केल करना संभव हो गया। लेकिन एक ही समय में, विभिन्न परियोजनाओं का कोड आधार प्रणाली स्तर पर काफी मजबूती से प्रतिच्छेद करता है। यह वास्तव में इसका मतलब था कि रेलवे परियोजना में परिवर्तन हमारे अपने विमान को प्रभावित कर सकते हैं। और अक्सर छूता था। उदाहरण के लिए, रेलवे में भुगतान के साथ काम का विस्तार करना आवश्यक था - यह साझा पुस्तकालय का एक संशोधन है। और विमान इसके साथ काम करता है, इसलिए, संयुक्त परीक्षण की आवश्यकता है। हमने परीक्षणों के साथ निर्भरता की जांच की, और यह कमोबेश सामान्य थी। 2009 में भी, विधि काफी उन्नत थी। लेकिन फिर भी, लोड एक संसाधन से दूसरे को जोड़ सकता है। डेटाबेस में एक चौराहा था, जिसके कारण एक उत्पाद में स्थानीय समस्याओं के साथ साइट पर ब्रेक के रूप में अप्रिय प्रभाव पड़ता था। डेटाबेस पर भारी प्रश्नों के कारण रेलवे ने डिस्क पर कई बार विमान को मार दिया।

हमने उदाहरणों को जोड़कर और उनके बीच संतुलन बनाकर बढ़ाया। मोनोलिथ जैसा है।

टायर की उम्र

फिर हम एक सीमांत मार्ग के साथ चले गए। एक तरफ, हमने सेवाओं को अलग करना शुरू कर दिया (आज इस दृष्टिकोण को माइक्रोसर्विस कहा जाता है, लेकिन हमें "माइक्रो" शब्द नहीं पता था), लेकिन बातचीत के लिए हमने डेटा ट्रांसफर के लिए बस का उपयोग करना शुरू कर दिया, बल्कि आरईएसटी या जीआरपीसी, जैसा कि अब करते हैं। हमने प्रोटोकॉल के रूप में एएमक्यूपी चुना, और मैसेज ब्रोकर के रूप में रैबिटएमक्यू। उस समय तक, हमने PHP के लिए डेमोंस के लॉन्च में काफी प्रसिद्ध भूमिका निभाई थी (हाँ, पूरी तरह से काम करने वाला कांटा है (कार्यान्वयन और प्रक्रियाओं के साथ काम करने के लिए और सब कुछ), क्योंकि मोनोलिथ में लंबे समय तक हमने गियरमैन द्वारा आरक्षण प्रणालियों के अनुरोधों को समानांतर बनाने के लिए ऐसी चीज का इस्तेमाल किया था। ।

उन्होंने खरगोश के ऊपर एक दलाल बनाया, और यह पता चला कि यह सब वास्तव में लोड के तहत नहीं रहता है। किसी तरह का नेटवर्क लॉस, रिट्रांसमिट्स, देरी। उदाहरण के लिए, कई दलालों का एक समूह "बॉक्स से बाहर" डेवलपर द्वारा कहा गया कुछ हद तक अलग व्यवहार करता है (यह पहले कभी नहीं हुआ, और फिर से)। सामान्य तौर पर, उन्होंने बहुत कुछ सीखा। लेकिन अंत में, हमें सेवाओं के लिए आवश्यक SLAs मिला। उदाहरण के लिए, सबसे भरी हुई आरपीएस सेवा में 400 आरपीएस है, क्लाइंट से क्लाइंट तक 35 एमएस की ऑर्डर की बस और सर्विस प्रोसेसिंग सहित 99 वीं प्रतिशताइल राउंड-ट्रिप। अब कुल मिलाकर हम लगभग 18 krps का निरीक्षण करते हैं।

फिर बसों की दिशा आई। हमने तुरंत इसे सेवा वास्तुकला पर एक मोनोलिथ के बिना लिखा था। चूंकि सब कुछ खरोंच से लिखा गया था, यह बहुत अच्छी तरह से, जल्दी और आसानी से निकला, हालांकि एक नए दृष्टिकोण के लिए उपकरणों को लगातार परिष्कृत करना आवश्यक था। हां, यह सब आभासी मशीनों पर घूम रहा था, जिसके अंदर PHP डेमोंस बस के माध्यम से संवाद करते हैं। डॉकर कंटेनरों के अंदर दानव शुरू हो गए, लेकिन ओपेंशिफ्ट या कुबेरनेट्स जैसे ऑर्केस्ट्रेशन के लिए कोई समाधान नहीं थे। 2014 में, हम इसके बारे में बात करना शुरू कर रहे थे, लेकिन हमने बिक्री के लिए इस तरह के दृष्टिकोण पर विचार नहीं किया।

यदि आप विमान या ट्रेन टिकटों की तुलना में कितने बस टिकट बेचे जाते हैं, तो आपको बाल्टी में एक बूंद मिलती है। और ट्रेनों और विमानों में, एक नई वास्तुकला के लिए आगे बढ़ना मुश्किल था, क्योंकि काम की कार्यक्षमता, एक वास्तविक भार था, और तकनीकी ऋण का भुगतान करने पर कुछ नया करने या पैसा खर्च करने के बीच हमेशा एक विकल्प था।

सेवाओं में जाना एक अच्छी बात है, लेकिन एक लंबा है, लेकिन आपको अब लोड और विश्वसनीयता से निपटने की आवश्यकता है। इसलिए, समानांतर में, उन्होंने मोनोलिथ के जीवन को बेहतर बनाने के लिए लक्षित उपाय करना शुरू कर दिया। बैकएंड्स को उत्पाद प्रकारों में विभाजित किया गया था, यानी, उन्होंने अपने प्रकार के आधार पर अनुरोधों के मार्ग को और अधिक लचीले ढंग से नियंत्रित करना शुरू किया: रेलवे से अलग हवा, आदि। लोड, पैमाने की स्वतंत्र रूप से भविष्यवाणी करना संभव था। जब वे जानते थे कि रेलवे में, उदाहरण के लिए, नए साल की बिक्री का चरम है, तो आभासी मशीनों के कई उदाहरण जोड़े गए थे। यह तब वर्ष के अंतिम कार्य दिवस से ठीक 45 दिन पहले शुरू हुआ था, और 14-15 नवंबर को हमारे ऊपर दोहरा भार था। अब एफपीके और अन्य वाहकों ने 60, 90 और यहां तक ​​कि 120 दिनों के लिए बिक्री की शुरुआत के साथ कई टिकट बनाए हैं, और यह शिखर फैल गया है। लेकिन अप्रैल के अंतिम कार्य दिवस पर मई से पहले हमेशा इलेक्ट्रिक ट्रेनों पर भार रहेगा, और अभी भी चोटियां हैं। लेकिन टिकटों की मौसम की स्थिति और रेलवे से मेरे सहयोगियों के विमुद्रीकरण के प्रवास के तरीके बेहतर बताएंगे, और मैं वास्तुकला के बारे में जारी रखूंगा।

2014 में, उन्होंने कई छोटे लोगों के एक बड़े डेटाबेस को पटरी से उतारना शुरू कर दिया। यह महत्वपूर्ण था क्योंकि यह खतरनाक रूप से बढ़ रहा था, और गिरावट महत्वपूर्ण थी। हमने एक विशिष्ट कार्यक्षमता के लिए अलग-अलग छोटे डेटाबेस (5-10 टेबल के लिए) आवंटित करना शुरू किया, ताकि अन्य सेवाएं कम व्यवधानों को प्रभावित करें, और ताकि यह सब आसान हो सके। यह ध्यान देने योग्य है कि लोड संतुलन और स्केलिंग के लिए हमने पढ़ने के लिए प्रतिकृतियां का उपयोग किया। प्रतिकृति की विफलता के बाद एक बड़े आधार के लिए प्रतिकृतियां प्राप्त करने में घंटों लग सकते हैं, और इस बार मुझे "पैरोल पर और एक पंख पर उड़ना पड़ा।" इस तरह की अवधि की यादें अभी भी कानों के बीच एक अप्रिय ठंड का कारण बनती हैं। अब हमारे पास विभिन्न ठिकानों के लगभग 200 उदाहरण हैं, और हमारे हाथों से इतने सारे प्रतिष्ठानों का प्रशासन एक श्रमसाध्य और अविश्वसनीय व्यवसाय है। इसलिए, हम गिथुब ऑर्केस्ट्रेटर का उपयोग करते हैं, जो लोड को वितरित करने और किसी विशेष डेटाबेस की विफलता से बचाने के लिए प्रतिकृतियों और प्रॉक्सीस्केल के साथ काम को स्वचालित करता है।

अभी की तरह

सामान्य तौर पर, हमने धीरे-धीरे अतुल्यकालिक कार्यों को आवंटित करना शुरू कर दिया और इवेंट हैंडलर में उनके लॉन्च को अलग कर दिया ताकि कोई दूसरे के साथ हस्तक्षेप न करे।

जब PHP 7 बाहर आया, तो हमने परीक्षणों में प्रदर्शन और संसाधन खपत को कम करने में बहुत बड़ी प्रगति देखी। थोड़ा बवासीर के साथ आगे बढ़ना, परीक्षणों की शुरुआत से लेकर पूरे उत्पादन के संपूर्ण अनुवाद तक की पूरी परियोजना को छह महीने से थोड़ा अधिक समय लगा, लेकिन इसके बाद संसाधनों की खपत लगभग दो बार गिर गई। सीपीयू लोड समयरेखा - पोस्ट के शीर्ष पर।

मोनोलिथ आज तक जीवित है और मेरे अनुमान में, कोड आधार का लगभग 40% है। यह कहने योग्य है कि संपूर्ण मोनोलिथ को सेवाओं के साथ बदलने का कार्य स्पष्ट रूप से निर्धारित नहीं है। हम व्यावहारिक रूप से आगे बढ़ रहे हैं: सब कुछ नया किया जाता है, जो कि माइक्रोसोर्विस पर किया जाता है, लेकिन अगर आपको एक मोनोलिथ में पुरानी कार्यक्षमता को परिष्कृत करने की आवश्यकता है, तो हम इसे सेवा वास्तुकला में स्थानांतरित करने की कोशिश करते हैं, अगर केवल शोधन वास्तव में बहुत छोटा नहीं है। इसी समय, मोनोलिथ को परीक्षणों में शामिल किया गया है ताकि हम सप्ताह में दो बार पर्याप्त स्तर की गुणवत्ता के साथ तैनात कर सकें। विशेषताएं अलग-अलग तरीकों से कवर की जाती हैं, यूनिट परीक्षण काफी पूर्ण होते हैं, यूआई परीक्षण और स्वीकृति परीक्षण लगभग पूरे पोर्टल कार्यक्षमता को कवर करते हैं (हमारे पास लगभग 15,000 परीक्षण मामले हैं), एपीआई परीक्षण अधिक या कम पूर्ण हैं। हम लगभग लोड परीक्षण नहीं करते हैं। अधिक सटीक रूप से, हमारे मंचन संरचना में ठेस के समान है, लेकिन सत्ता में नहीं है, और एक ही निगरानी के साथ पंक्तिबद्ध है। हम एक लोड उत्पन्न करते हैं, अगर हम देखते हैं कि पुरानी रिलीज पर पिछला रन टाइमिंग में भिन्न है, तो हम देखते हैं कि यह कितना महत्वपूर्ण है। यदि नई रिलीज़ और पुरानी लगभग समान हैं, तो हम उन्हें ठेस में जारी करते हैं। किसी भी स्थिति में, सभी सुविधाएँ स्विच के नीचे जाती हैं ताकि आप इसे किसी भी सेकंड में बंद कर सकें यदि कुछ गलत हो जाता है।

1% उपयोगकर्ताओं के लिए भारी सुविधाओं का हमेशा परीक्षण किया जाता है। फिर हम 2%, 5%, 10% पर जाते हैं और इसलिए हम सभी उपयोगकर्ताओं तक पहुँचते हैं। अर्थात्, सर्वर्स को मारने और अग्रिम में डिस्कनेक्ट करने से पहले हम हमेशा एटिपिकल लोड देख सकते हैं।

जहां आवश्यक हो, हमने एक पुनर्रचना परियोजना के लिए 4-5 महीने का समय लिया (और लेंगे), जब टीम एक विशिष्ट कार्य पर ध्यान केंद्रित करती है। यह गॉर्डियन गाँठ को काटने का एक अच्छा तरीका है जब स्थानीय रीफैक्टरिंग अब मदद नहीं करता है। इसलिए हमने कुछ साल पहले हवा के साथ किया: हमने वास्तुकला को फिर से बनाया, किया - तुरंत विकास में त्वरित त्वरण प्राप्त किया, कई नई सुविधाओं को लॉन्च करने में सक्षम थे। पुनर्रचना के दो महीने बाद, वे विशेषताओं के कारण ग्राहकों के लिए परिमाण के क्रम से बढ़ गए। उन्होंने कीमतों को अधिक सटीक रूप से प्रबंधित करना शुरू कर दिया, भागीदारों को जोड़ते हुए, सब कुछ तेज हो गया। जोय। मुझे कहना होगा, अब फिर से वही काम करने का समय आ गया है, लेकिन यह भाग्य है: अनुप्रयोगों के निर्माण के तरीके बदल रहे हैं, नए समाधान, दृष्टिकोण, उपकरण दिखाई दे रहे हैं। व्यवसाय में बने रहने के लिए, आपको बढ़ने की आवश्यकता है।

हमारे लिए पुनर्रचना का मुख्य कार्य विकास को और तेज करना है। अगर कुछ भी नया नहीं चाहिए, तो पुनर्रचना की जरूरत नहीं है। नया आविष्कार करने की आवश्यकता नहीं है: यह आधुनिकीकरण में निवेश करने का कोई मतलब नहीं है। और इसलिए, एक आधुनिक स्टैक और वास्तुकला को बनाए रखते हुए, लोग तेजी से काम में लग जाते हैं, एक नया तेजी से जुड़ता है, सिस्टम अधिक अनुमान लगाता है, डेवलपर्स एक परियोजना पर काम करने में अधिक रुचि रखते हैं। अब मोनोलिथ को पूरी तरह से फेंकने के बिना खत्म करने का एक कार्य है, ताकि प्रत्येक उत्पाद अपडेट अपलोड कर सके, दूसरों पर निर्भर नहीं। यही है, एक मोनोलिथ में एक विशिष्ट सीआई / सीडी प्राप्त करें।

आज हम सेवाओं के बीच सूचनाओं के आदान-प्रदान के लिए न केवल खरगोश, बल्कि REST और gRPC का उपयोग करते हैं। कुछ माइक्रोसॉर्क्स गोलंग में लिखे गए हैं: कम्प्यूटेशनल गति और मेमोरी हैंडलिंग वहां उत्कृष्ट हैं। नोडजेएस समर्थन को लागू करने के लिए एक कॉल था, लेकिन अंत में हमने नोड को केवल सर्वर रेंडरिंग के लिए छोड़ दिया, और व्यापारिक तर्क PHP और गो में छोड़ दिया गया। सिद्धांत रूप में, चुना हुआ दृष्टिकोण हमें लगभग किसी भी भाषा में सेवाएं विकसित करने की अनुमति देता है, लेकिन हमने चिड़ियाघर को सीमित करने का निर्णय लिया ताकि सिस्टम की जटिलता को न बढ़ाया जा सके।

अब हम उन माइक्रोसर्विसेस पर जाते हैं जो ओपनशफ्ट ऑर्केस्ट्रेशन के तहत डॉक कंटेनर में काम करेंगे। एक साल और एक आधे के भीतर कार्य - मंच के अंदर सभी का 90% मोड़। क्यों? तो यह तैनात करने के लिए तेज़ है, संस्करणों की जांच करने के लिए तेज़ है, डेवेल पर्यावरण से बिक्री में कम अंतर है। डेवलपर उस सुविधा के बारे में अधिक सोच सकता है जिसे वह लागू करता है, और इस बारे में नहीं कि पर्यावरण को कैसे तैनात किया जाए, इसे कैसे कॉन्फ़िगर किया जाए, इसे कहां से शुरू किया जाए, अर्थात अधिक लाभ। फिर से - परिचालन संबंधी समस्याएं: कई माइक्रोसेवर्सी हैं, उन्हें प्रबंधन द्वारा स्वचालित करने की आवश्यकता है। मैन्युअल रूप से - बहुत अधिक लागत, मैन्युअल नियंत्रण के साथ त्रुटियों का जोखिम, और मंच सामान्य स्केलिंग देता है।

हर साल हमारे पास कार्यभार में वृद्धि होती है - 30-40% तक: अधिक से अधिक लोग इंटरनेट के साथ ट्रिक्स सीखते हैं, भौतिक नकदी डेस्क पर जाना बंद करते हैं, हम मौजूदा वाले नए उत्पादों और सुविधाओं को जोड़ते हैं। अब एक दिन में लगभग 1 मिलियन उपयोगकर्ता पोर्टल पर आते हैं। बेशक, सभी उपयोगकर्ता समान लोड उत्पन्न नहीं करते हैं। कुछ को कम्प्यूटेशनल संसाधनों की आवश्यकता नहीं होती है, और, उदाहरण के लिए, खोज एक संसाधन-गहन घटक हैं। वहां, विमानन में एक एकल टिक "प्लस या माइनस तीन दिन" 49 बार लोड बढ़ाता है (जब आगे और पीछे देखा जाता है, तो मैट्रिक्स 7 से 7 तक होता है)। रेलवे सिस्टम और हवाई के अंदर टिकट की खोज के साथ तुलना में सब कुछ काफी सरल है। संसाधनों में सबसे आसान चीज साहसिक और भ्रमण खोज है (वास्तुकला के संदर्भ में सबसे आसान कैश नहीं है, लेकिन फिर भी टिकट संयोजनों की तुलना में बहुत कम पर्यटन हैं), फिर ट्रेन शेड्यूल (यह आसानी से मानक तरीकों से कैश किया जाता है), और उसके बाद ही सब कुछ ।

बेशक, तकनीकी ऋण अभी भी ढेर है। सब तरफ से। मुख्य बात यह है कि उस समय को समझना चाहिए जब आप रिफ्लेक्टर को प्रबंधित कर सकते हैं, और सब कुछ ठीक हो जाएगा, जहां आपको कुछ भी छूने की ज़रूरत नहीं है (कभी-कभी ऐसा होता है: हम लिगेसी के साथ रहते हैं यदि कोई बदलाव योजनाबद्ध नहीं हैं), लेकिन कहीं न कहीं हमें खुद को दौड़ने और पुन: पेश करने की आवश्यकता है, क्योंकि इस भविष्य के बिना नहीं होगा बेशक, हम गलतियाँ करते हैं, लेकिन सामान्य तौर पर, टूटुव्यू को लगभग 16 साल हो गए हैं, और मुझे परियोजना की गतिशीलता पसंद है।