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

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

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

लिनक्स हो सर्भर कोठा अपरेटिङ सिस्टम, र प्रायः तपाईको अनुप्रयोगहरू यस OS मा चल्छन्। यद्यपि म "लिनक्स" भन्छु, प्राय जसो तपाईले सुरक्षित रूपमा मान्न सक्नुहुन्छ कि मेरो मतलब सामान्य रूपमा सबै युनिक्स-जस्तो अपरेटिङ सिस्टम हो। यद्यपि, मैले अन्य प्रणालीहरूमा सँगैको कोड परीक्षण गरेको छैन। त्यसोभए, यदि तपाइँ FreeBSD वा OpenBSD मा रुचि राख्नुहुन्छ भने, तपाइँको नतिजा फरक हुन सक्छ। जब म लिनक्स-विशिष्ट केहि प्रयास गर्छु, म यसलाई औंल्याउँछु।

तपाईंले यो ज्ञानलाई स्क्र्याचबाट एप निर्माण गर्न प्रयोग गर्न सक्नुहुन्छ र यो पूर्ण रूपमा अप्टिमाइज हुनेछ, त्यसो नगर्नु नै उत्तम हुन्छ। यदि तपाइँ तपाइँको संगठनको व्यावसायिक अनुप्रयोगको लागि C वा C++ मा नयाँ वेब सर्भर लेख्नुहुन्छ भने, यो तपाइँको कामको अन्तिम दिन हुन सक्छ। यद्यपि, यी अनुप्रयोगहरूको संरचना थाहा पाउँदा अवस्थित कार्यक्रमहरू छनोट गर्न मद्दत गर्नेछ। तपाइँ प्रक्रिया-आधारित प्रणालीहरू थ्रेड-आधारित प्रणालीहरू साथै घटना-आधारित प्रणालीहरूसँग तुलना गर्न सक्षम हुनुहुनेछ। तपाईंले बुझ्नुहुनेछ र प्रशंसा गर्नुहुनेछ किन Nginx ले Apache httpd भन्दा राम्रो प्रदर्शन गर्दछ, किन टोर्नाडो आधारित पाइथन अनुप्रयोगले Django आधारित पाइथन अनुप्रयोगको तुलनामा धेरै प्रयोगकर्ताहरूलाई सेवा दिन सक्छ।

ZeroHTTPd: सिकाउने उपकरण

ZeroHTTPd एउटा वेब सर्भर हो जुन मैले स्क्र्याचबाट C मा शिक्षण उपकरणको रूपमा लेखेको छु। यसमा Redis मा पहुँच सहित कुनै बाह्य निर्भरता छैन। हामी हाम्रो आफ्नै Redis प्रक्रियाहरू चलाउँछौं। थप विवरणहरूको लागि तल हेर्नुहोस्।

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

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

ZeroHTTPd गृह पृष्ठ। यसले छविहरू सहित विभिन्न फाइल प्रकारहरू आउटपुट गर्न सक्छ

अतिथि पुस्तक आवेदन

आधुनिक वेब अनुप्रयोगहरू सामान्यतया स्थिर फाइलहरूमा सीमित छैनन्। तिनीहरूसँग विभिन्न डाटाबेसहरू, क्यासहरू, इत्यादिसँग जटिल अन्तरक्रियाहरू छन्। त्यसैले हामी "गेस्ट बुक" भनिने एउटा साधारण वेब अनुप्रयोग सिर्जना गर्नेछौं जहाँ आगन्तुकहरूले उनीहरूको नाममा प्रविष्टिहरू छोड्छन्। अतिथि पुस्तक भण्डार प्रविष्टिहरू पहिले बाँकी छ। पृष्ठको तल एक आगन्तुक काउन्टर पनि छ।

वेब अनुप्रयोग "गेस्ट बुक" ZeroHTTPd

आगन्तुक काउन्टर र अतिथि पुस्तक प्रविष्टिहरू Redis मा भण्डारण गरिएका छन्। Redis सँग संचारको लागि, आफ्नै प्रक्रियाहरू लागू गरिन्छ; तिनीहरू बाह्य पुस्तकालयमा निर्भर हुँदैनन्। सार्वजनिक रूपमा उपलब्ध र राम्रोसँग परीक्षण गरिएका समाधानहरू हुँदा म होमब्रू कोड रोल आउट गर्ने ठूलो प्रशंसक होइन। तर ZeroHTTPd को उद्देश्य लिनक्स प्रदर्शन र बाह्य सेवाहरूमा पहुँच अध्ययन गर्नु हो, जबकि HTTP अनुरोधहरू सेवा गर्दा गम्भीर प्रदर्शन प्रभाव हुन्छ। हामीले हाम्रो प्रत्येक सर्भर आर्किटेक्चरमा Redis सँग संचारलाई पूर्ण रूपमा नियन्त्रण गर्नुपर्छ। केही आर्किटेक्चरहरूमा हामी ब्लकिङ कलहरू प्रयोग गर्छौं, अरूमा हामी घटना-आधारित प्रक्रियाहरू प्रयोग गर्छौं। बाह्य Redis ग्राहक पुस्तकालय प्रयोग गरेर यो नियन्त्रण प्रदान गर्दैन। थप रूपमा, हाम्रो सानो रेडिस क्लाइन्टले केही कार्यहरू मात्र गर्दछ (कुञ्जी प्राप्त गर्ने, सेटिङ गर्ने, र वृद्धि गर्ने; प्राप्त गर्ने र एर्रेमा जोड्ने)। थप रूपमा, Redis प्रोटोकल अत्यन्त सुरुचिपूर्ण र सरल छ। तपाईंले यसलाई विशेष रूपमा सिकाउनु पनि आवश्यक छैन। प्रोटोकलले लगभग सय लाइनको कोडमा सबै काम गर्छ भन्ने तथ्यले यो कत्तिको राम्रोसँग सोचेको छ भनेर देखाउँछ।

निम्न चित्रले क्लाइन्ट (ब्राउजर) अनुरोध गर्दा अनुप्रयोगले के गर्छ देखाउँछ /guestbookURL.

अतिथि पुस्तक आवेदन कसरी काम गर्दछ

जब अतिथि पुस्तक पृष्ठ जारी गर्न आवश्यक छ, त्यहाँ टेम्प्लेट मेमोरीमा पढ्न फाइल प्रणालीमा एउटा कल र Redis मा तीन नेटवर्क कलहरू छन्। टेम्प्लेट फाइलले माथिको स्क्रिनसटमा पृष्ठको लागि धेरै जसो HTML सामग्री समावेश गर्दछ। त्यहाँ सामग्रीको गतिशील भागको लागि विशेष प्लेसहोल्डरहरू पनि छन्: पोष्टहरू र आगन्तुक काउन्टर। हामी तिनीहरूलाई Redis बाट प्राप्त गर्छौं, तिनीहरूलाई पृष्ठमा घुसाउँछौं र ग्राहकलाई पूर्ण रूपमा बनाइएको सामग्री प्रदान गर्दछौं। Redis लाई तेस्रो कल बेवास्ता गर्न सकिन्छ किनभने Redis ले नयाँ कुञ्जी मान फिर्ता गर्छ जब वृद्धि हुन्छ। यद्यपि, हाम्रो सर्भरको लागि, जसमा एक एसिन्क्रोनस घटना-आधारित वास्तुकला छ, धेरै नेटवर्क कलहरू सिक्ने उद्देश्यका लागि राम्रो परीक्षण हो। त्यसैले हामी आगन्तुकहरूको संख्याको Redis फिर्ता मान खारेज गर्छौं र यसलाई छुट्टै कलको साथ क्वेरी गर्छौं।

सर्भर आर्किटेक्चर ZeroHTTPd

हामी समान कार्यक्षमता तर फरक आर्किटेक्चरको साथ ZeroHTTPd को सात संस्करणहरू निर्माण गर्दैछौं:

• पुनरावृत्ति
• फोर्क सर्भर (प्रति अनुरोध एक बच्चा प्रक्रिया)
• पूर्व-फोर्क सर्भर (प्रक्रियाहरूको पूर्व-फोर्किङ)
• कार्यान्वयन थ्रेडहरूसँग सर्भर (प्रति अनुरोध एक थ्रेड)
• पूर्व-थ्रेड सिर्जना भएको सर्भर
• वास्तुकला आधारित poll()
• वास्तुकला आधारित epoll

हामी HTTP अनुरोधहरूको साथ सर्भर लोड गरेर प्रत्येक वास्तुकलाको प्रदर्शन मापन गर्छौं। तर अत्यधिक समानान्तर वास्तुकलाहरू तुलना गर्दा, प्रश्नहरूको संख्या बढ्छ। हामी तीन पटक परीक्षण गर्छौं र औसत गणना गर्छौं।

परीक्षण पद्धति

ZeroHTTPd लोड परीक्षण सेटअप

यो महत्त्वपूर्ण छ कि परीक्षणहरू चलाउँदा, सबै कम्पोनेन्टहरू एउटै मेसिनमा चल्दैनन्। यस अवस्थामा, OS ले अतिरिक्त शेड्युलिङ ओभरहेड लगाउँछ किनकि कम्पोनेन्टहरू CPU का लागि प्रतिस्पर्धा गर्छन्। प्रत्येक चयन गरिएको सर्भर आर्किटेक्चरको अपरेटिङ सिस्टम ओभरहेड मापन यस अभ्यासको सबैभन्दा महत्त्वपूर्ण लक्ष्यहरू मध्ये एक हो। थप चरहरू थप्दा प्रक्रियामा हानिकारक हुनेछ। तसर्थ, माथिको चित्रमा सेटिङ राम्रो काम गर्दछ।

यी प्रत्येक सर्भरले के गर्छ?

• load.unixism.net: हामी यहाँ चल्छौं ab, अपाचे बेन्चमार्क उपयोगिता। यसले हाम्रो सर्भर आर्किटेक्चर परीक्षण गर्न आवश्यक लोड उत्पन्न गर्दछ।
• nginx.unixism.net: कहिलेकाहीँ हामी सर्भर प्रोग्रामको एक भन्दा बढी उदाहरणहरू चलाउन चाहन्छौं। यो गर्नका लागि, उपयुक्त सेटिङहरूसँग Nginx सर्भरले लोड ब्यालेन्सरको रूपमा काम गर्दछ ab हाम्रो सर्भर प्रक्रियाहरूमा।
• zerohttpd.unixism.net: यहाँ हामी हाम्रो सर्भर प्रोग्रामहरू सात फरक आर्किटेक्चरहरूमा चलाउँछौं, एक पटकमा।
• redis.unixism.net: यो सर्भरले रेडिस डेमन चलाउँछ, जहाँ गेस्टबुक प्रविष्टिहरू र आगन्तुक काउन्टरहरू भण्डारण गरिन्छ।

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

हामी के मापन गर्दैछौं?

तपाईं विभिन्न सूचकहरू मापन गर्न सक्नुहुन्छ। हामी प्रत्येक आर्किटेक्चरको कार्यसम्पादनलाई दिइएको कन्फिगरेसनमा समानान्तरताका विभिन्न स्तरहरूमा अनुरोधहरूको साथ सर्भरहरू लोड गरेर मूल्याङ्कन गर्छौं: लोड 20 देखि 15 समवर्ती प्रयोगकर्ताहरूमा बढ्छ।

परीक्षण नतीजा

निम्न चार्टले समानान्तरको विभिन्न स्तरहरूमा विभिन्न संरचनाहरूमा सर्भरहरूको प्रदर्शन देखाउँछ। y-अक्ष प्रति सेकेन्ड अनुरोधहरूको संख्या हो, x-अक्ष समानान्तर जडानहरू हो।

तल नतिजा संग तालिका छ।

प्रति सेकेन्ड अनुरोधहरू

समानन्तरता
पुनरावृत्ति
काँटा
पूर्व काँटा
स्ट्रिमि
पूर्व-स्ट्रिमिङ
सर्वेक्षण
epoll

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
ठूलो फैलावट
2138

5000
-
ठूलो फैलावट
1600
1100
2519
-
2235

8000
-
-
1200
ठूलो फैलावट
2451
-
2100

१०,२10
-
-
ठूलो फैलावट
-
2200
-
2200

१०,२11
-
-
-
-
2200
-
2122

१०,२12
-
-
-
-
970
-
1958

१०,२13
-
-
-
-
730
-
1897

१०,२14
-
-
-
-
590
-
1466

१०,२15
-
-
-
-
532
-
1281

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

ZeroHTTPd स्रोत कोड

ZeroHTTPd स्रोत कोड यहाँ। प्रत्येक वास्तुकलाको लागि छुट्टै डाइरेक्टरी छ।

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── main.c ├── 03_preforking ├── main. 04_ थ्रेडिङ │ ├── main.c ├── 05_प्रिथ्रेडिङ │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ ├─── main.c ├├le─le─ main.c ├ बनाउनुहोस् ├── अनुक्रमणिका .html │ └── टक्स png └── टेम्प्लेटहरू └── अतिथि पुस्तिका └── index.html

सबै आर्किटेक्चरका लागि सात डाइरेक्टरीहरू बाहेक, शीर्ष-स्तर डाइरेक्टरीमा दुई थप छन्: सार्वजनिक र टेम्प्लेटहरू। पहिलोमा index.html फाइल र पहिलो स्क्रिनसटको छवि समावेश छ। तपाइँ त्यहाँ अन्य फाइलहरू र फोल्डरहरू राख्न सक्नुहुन्छ, र ZeroHTTPd ले ती स्थिर फाइलहरूलाई कुनै पनि समस्या बिना सेवा गर्नुपर्छ। यदि ब्राउजरको पथ सार्वजनिक फोल्डरमा रहेको पथसँग मेल खान्छ भने, ZeroHTTPd ले यस डाइरेक्टरीमा index.html फाइल खोज्छ। अतिथि पुस्तकको लागि सामग्री गतिशील रूपमा उत्पन्न हुन्छ। यसमा केवल एउटा गृह पृष्ठ छ, र यसको सामग्री फाइल 'templates/guestbook/index.html' मा आधारित छ। ZeroHTTPd सजिलैसँग विस्तारको लागि गतिशील पृष्ठहरू थप्छ। विचार यो हो कि प्रयोगकर्ताहरूले यस डाइरेक्टरीमा टेम्प्लेटहरू थप्न सक्छन् र आवश्यकता अनुसार ZeroHTTPd विस्तार गर्न सक्छन्।

सबै सात सर्भरहरू निर्माण गर्न, चलाउनुहोस् make all शीर्ष-स्तर डाइरेक्टरीबाट - र सबै निर्माणहरू यस डाइरेक्टरीमा देखा पर्नेछ। कार्यान्वयनयोग्य फाइलहरूले सार्वजनिक र टेम्प्लेट डाइरेक्टरीहरू डाइरेक्टरीमा खोज्छन् जहाँबाट तिनीहरू सुरु हुन्छन्।

लिनक्स API

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

प्रदर्शन र स्केलेबिलिटी

प्रदर्शन र स्केलेबिलिटी बारे एक नोट। सैद्धान्तिक रूपमा, तिनीहरू बीच कुनै सम्बन्ध छैन। तपाइँसँग केहि मिलिसेकेन्डको प्रतिक्रिया समय संग धेरै राम्रो काम गर्ने वेब सेवा हुन सक्छ, तर यो मापन गर्दैन। त्यस्तै गरी, त्यहाँ खराब प्रदर्शन गर्ने वेब अनुप्रयोग हुन सक्छ जसले प्रतिक्रिया दिन केही सेकेन्ड लिन्छ, तर यसले दसौं हजारौं समवर्ती प्रयोगकर्ताहरूलाई ह्यान्डल गर्न दसौंले मापन गर्दछ। यद्यपि, उच्च प्रदर्शन र स्केलेबिलिटीको संयोजन एक धेरै शक्तिशाली संयोजन हो। उच्च-सम्पादन अनुप्रयोगहरूले सामान्यतया स्रोतहरू थोरै प्रयोग गर्छन् र यसरी लागत घटाउँदै सर्भरमा अधिक समवर्ती प्रयोगकर्ताहरूलाई कुशलतापूर्वक सेवा दिन्छन्।

CPU र I/O कार्यहरू

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

सर्भर आर्किटेक्चर बारे थप जान्नुहोस्

1. भाग I: पुनरावृत्ति वास्तुकला
2. भाग II। फोर्क सर्भरहरू
3. भाग III। पूर्व-फोर्क सर्भरहरू
4. भाग IV। निष्पादनको थ्रेडहरू भएका सर्भरहरू
5. भाग V. पूर्व-थ्रेडेड सर्भरहरू
6. भाग VI। पोल आधारित वास्तुकला
7. भाग VII। इपोल आधारित वास्तुकला

स्रोत: www.habr.com