वेब ऍप्लिकेशन्स आता सर्वत्र वापरले जातात आणि सर्व ट्रान्सपोर्ट प्रोटोकॉलमध्ये, HTTP चा मोठा वाटा आहे. वेब ऍप्लिकेशन डेव्हलपमेंटच्या बारीकसारीक गोष्टींचा अभ्यास करताना, बहुतेक लोक ऑपरेटिंग सिस्टमकडे फारच कमी लक्ष देतात जेथे हे ऍप्लिकेशन प्रत्यक्षात चालतात. डेव्हलपमेंट (देव) आणि ऑपरेशन्स (ऑप्स) वेगळे केल्याने परिस्थिती आणखी बिघडली. परंतु DevOps संस्कृतीच्या वाढीसह, डेव्हलपर त्यांचे ऍप्लिकेशन क्लाउडमध्ये चालविण्यासाठी जबाबदार बनत आहेत, त्यामुळे ऑपरेटिंग सिस्टमच्या बॅकएंडशी पूर्णपणे परिचित होणे त्यांच्यासाठी खूप उपयुक्त आहे. हे विशेषतः उपयुक्त आहे जर तुम्ही हजारो किंवा हजारो एकाचवेळी कनेक्शनसाठी सिस्टम तैनात करण्याचा प्रयत्न करत असाल.

वेब सेवांमधील मर्यादा इतर अनुप्रयोगांसारख्याच आहेत. लोड बॅलन्सर किंवा डेटाबेस सर्व्हर असोत, या सर्व ऍप्लिकेशन्सना उच्च-कार्यक्षमता वातावरणात समान समस्या आहेत. या मूलभूत मर्यादा समजून घेणे आणि त्यावर सर्वसाधारणपणे मात कशी करायची हे तुम्हाला तुमच्या वेब अॅप्लिकेशन्सच्या कार्यक्षमतेचे आणि स्केलेबिलिटीचे मूल्यांकन करण्यात मदत करेल.

मी या लेखांची मालिका तरुण विकासकांच्या प्रश्नांना उत्तर म्हणून लिहित आहे ज्यांना सुप्रसिद्ध सिस्टम आर्किटेक्ट बनायचे आहे. लिनक्स ऍप्लिकेशन ऑप्टिमायझेशन तंत्र ऑपरेटिंग सिस्टम स्तरावर ते कसे कार्य करतात या मूलभूत गोष्टींमध्ये डोकावल्याशिवाय स्पष्टपणे समजून घेणे अशक्य आहे. ऍप्लिकेशन्सचे अनेक प्रकार असले तरी, या मालिकेत मला ब्राउझर किंवा टेक्स्ट एडिटरसारख्या डेस्कटॉप ऍप्लिकेशन्सऐवजी वेब-आधारित ऍप्लिकेशन्स एक्सप्लोर करायचे आहेत. ही सामग्री विकसक आणि आर्किटेक्टसाठी आहे ज्यांना लिनक्स किंवा युनिक्स प्रोग्राम कसे कार्य करतात आणि उच्च कार्यक्षमतेसाठी त्यांची रचना कशी करावी हे समजून घ्यायचे आहे.

लिनक्स आहे सर्व्हर रूम ऑपरेटिंग सिस्टम, आणि बहुतेकदा तुमचे अॅप्लिकेशन या OS वर चालतात. जरी मी "Linux" म्हणत असलो तरी, बर्‍याच वेळा तुम्ही सुरक्षितपणे असे गृहीत धरू शकता की सर्वसाधारणपणे सर्व युनिक्स सारखी ऑपरेटिंग सिस्टम आहे. तथापि, मी इतर सिस्टमवर सोबतच्या कोडची चाचणी केलेली नाही. म्हणून, जर तुम्हाला FreeBSD किंवा OpenBSD मध्ये स्वारस्य असेल, तर तुमचे परिणाम बदलू शकतात. जेव्हा मी लिनक्स-विशिष्ट काहीतरी वापरून पाहतो, तेव्हा मी ते सूचित करतो.

तुम्ही हे ज्ञान सुरवातीपासून अॅप तयार करण्यासाठी वापरू शकता आणि ते उत्तम प्रकारे ऑप्टिमाइझ केले जाईल, असे न करणे चांगले. तुम्ही तुमच्या संस्थेच्या व्यवसाय अनुप्रयोगासाठी C किंवा C++ मध्ये नवीन वेब सर्व्हर लिहिल्यास, हा तुमचा नोकरीवरील शेवटचा दिवस असू शकतो. तथापि, या ऍप्लिकेशन्सची रचना जाणून घेतल्याने विद्यमान प्रोग्राम्स निवडण्यात मदत होईल. तुम्ही प्रक्रिया-आधारित प्रणालींची थ्रेड-आधारित सिस्टीम तसेच इव्हेंट-आधारित सिस्टीमशी तुलना करण्यास सक्षम असाल. Nginx Apache httpd पेक्षा चांगली कामगिरी का करते हे तुम्ही समजून घ्याल आणि प्रशंसा कराल, टोर्नाडो आधारित पायथन अॅप्लिकेशन जॅंगो आधारित पायथन अॅप्लिकेशनच्या तुलनेत अधिक वापरकर्त्यांना का सेवा देऊ शकते.

ZeroHTTPd: शिकण्याचे साधन

ZeroHTTPd एक वेब सर्व्हर आहे जो मी शिकवण्याचे साधन म्हणून C मध्ये सुरवातीपासून लिहिले आहे. रेडिसमध्ये प्रवेशासह त्यात कोणतेही बाह्य अवलंबित्व नाही. आम्ही आमच्या स्वतःच्या रेडिस प्रक्रिया चालवतो. अधिक तपशीलांसाठी खाली पहा.

जरी आपण सिद्धांतावर विस्तृत चर्चा करू शकलो तरी, कोड लिहिणे, ते चालवणे आणि सर्व सर्व्हर आर्किटेक्चर्सची एकमेकांशी तुलना करणे यापेक्षा चांगले काहीही नाही. ही सर्वात स्पष्ट पद्धत आहे. म्हणून, आम्ही प्रत्येक मॉडेल वापरून एक साधा ZeroHTTPd वेब सर्व्हर लिहू: प्रक्रिया-आधारित, थ्रेड-आधारित आणि इव्हेंट-आधारित. चला यापैकी प्रत्येक सर्व्हर तपासू आणि ते एकमेकांच्या तुलनेत कसे कार्य करतात ते पाहू. ZeroHTTPd एका C फाइलमध्ये लागू केले आहे. इव्हेंट-आधारित सर्व्हरमध्ये समाविष्ट आहे उथश, एक उत्कृष्ट हॅश सारणी अंमलबजावणी जे एकाच शीर्षलेख फाइलमध्ये येते. इतर प्रकरणांमध्ये, कोणतेही अवलंबित्व नाहीत, जेणेकरून प्रकल्पाची गुंतागुंत होऊ नये.

तुम्हाला समजण्यात मदत करण्यासाठी कोडमध्ये अनेक टिप्पण्या आहेत. कोडच्या काही ओळींमध्ये एक साधा वेब सर्व्हर असल्याने, ZeroHTTPd हे वेब डेव्हलपमेंटसाठी किमान फ्रेमवर्क आहे. त्याची कार्यक्षमता मर्यादित आहे, परंतु स्थिर फाइल्स आणि अतिशय साधी "डायनॅमिक" पृष्ठे सर्व्ह करण्यास सक्षम आहे. मला असे म्हणायचे आहे की उच्च-कार्यक्षमता लिनक्स अनुप्रयोग कसे तयार करावे हे शिकण्यासाठी ZeroHTTPd चांगले आहे. मोठ्या प्रमाणावर, बहुतेक वेब सेवा विनंत्यांची प्रतीक्षा करतात, त्या तपासतात आणि त्यावर प्रक्रिया करतात. ZeroHTTPd नक्की हेच करेल. हे शिकण्याचे साधन आहे, उत्पादन नाही. हे एरर हाताळताना चांगले नाही आणि सर्वोत्तम सुरक्षा पद्धतींचा अभिमान बाळगण्याची शक्यता नाही (अरे हो, मी वापरले strcpy) किंवा C भाषेच्या चतुर युक्त्या. परंतु मला आशा आहे की ते त्याचे कार्य चांगले करेल.

ZeroHTTPd मुख्यपृष्ठ. हे प्रतिमांसह विविध फाइल प्रकार आउटपुट करू शकते

अतिथी पुस्तक अर्ज

आधुनिक वेब ऍप्लिकेशन्स सामान्यतः स्टॅटिक फाइल्सपुरते मर्यादित नसतात. त्यांचा विविध डेटाबेस, कॅशे इत्यादींशी गुंतागुंतीचा संवाद आहे. म्हणून आम्ही "गेस्ट बुक" नावाचे एक साधे वेब ऍप्लिकेशन तयार करू जिथे अभ्यागत त्यांच्या नावाखाली नोंदी ठेवतात. अतिथी पुस्तक स्टोअरच्या नोंदी आधी सोडल्या जातात. पृष्ठाच्या तळाशी एक अभ्यागत काउंटर देखील आहे.

वेब ऍप्लिकेशन "गेस्ट बुक" ZeroHTTPd

अभ्यागत काउंटर आणि अतिथी पुस्तकाच्या नोंदी Redis मध्ये संग्रहित केल्या जातात. रेडिससह संप्रेषणासाठी, स्वतःच्या कार्यपद्धती लागू केल्या जातात; त्या बाह्य लायब्ररीवर अवलंबून नाहीत. सार्वजनिकरित्या उपलब्ध आणि चांगल्या प्रकारे चाचणी केलेले उपाय असताना मी होमब्रू कोड रोल आउट करण्याचा मोठा चाहता नाही. परंतु ZeroHTTPd चा उद्देश Linux कार्यप्रदर्शनाचा अभ्यास करणे आणि बाह्य सेवांमध्ये प्रवेश करणे हा आहे, तर HTTP विनंत्या सर्व्ह केल्याने कार्यक्षमतेवर गंभीर परिणाम होतो. आम्ही आमच्या प्रत्येक सर्व्हर आर्किटेक्चरमध्ये Redis सह संप्रेषण पूर्णपणे नियंत्रित केले पाहिजे. काही आर्किटेक्चरमध्ये आम्ही ब्लॉकिंग कॉल वापरतो, तर काहींमध्ये आम्ही इव्हेंट-आधारित प्रक्रिया वापरतो. बाह्य रेडिस क्लायंट लायब्ररी वापरणे हे नियंत्रण प्रदान करणार नाही. याव्यतिरिक्त, आमचा छोटा रेडिस क्लायंट फक्त काही कार्ये करतो (की मिळवणे, सेटिंग करणे आणि वाढवणे; अॅरे मिळवणे आणि जोडणे). याव्यतिरिक्त, रेडिस प्रोटोकॉल अत्यंत मोहक आणि साधे आहे. तुम्हाला ते विशेष शिकवण्याचीही गरज नाही. प्रोटोकॉल सर्व कार्य कोडच्या शंभर ओळींमध्ये करतो हे खरं आहे की ते किती चांगले आहे हे दर्शविते.

क्लायंट (ब्राउझर) विनंती करतो तेव्हा ऍप्लिकेशन काय करते हे खालील आकृती दाखवते /guestbookURL.

अतिथी पुस्तक अनुप्रयोग कसे कार्य करते

जेव्हा अतिथी पुस्तक पृष्ठ जारी करणे आवश्यक असते, तेव्हा मेमरीमध्ये टेम्पलेट वाचण्यासाठी फाइल सिस्टमला एक कॉल आणि Redis ला तीन नेटवर्क कॉल केले जातात. टेम्प्लेट फाइलमध्ये वरील स्क्रीनशॉटमधील पृष्ठासाठी बहुतेक HTML सामग्री आहे. सामग्रीच्या डायनॅमिक भागासाठी विशेष प्लेसहोल्डर देखील आहेत: पोस्ट आणि अभ्यागत काउंटर. आम्ही ते 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_पुनरावृत्ती │ ├── main.c ├── 02_forking │ ├── main.c ├── main.c ├── 03_preforking ├── main. 04_ थ्रेडिंग │ ├── main.c ├── 05_प्रीथ्रेडिंग │ ├── main.c ├── 06_मतदान │ ├── main.c ├── 07_epoll │ └── main.c ├├── main.c ├ सार्वजनिक करा ├── अनुक्रमणिका .html │ └── टक्स png └── टेम्पलेट्स └── अतिथीपुस्तक └── index.html

सर्व आर्किटेक्चर्ससाठी सात डिरेक्टरी व्यतिरिक्त, उच्च-स्तरीय निर्देशिकेत आणखी दोन आहेत: सार्वजनिक आणि टेम्पलेट्स. पहिल्यामध्ये index.html फाइल आणि पहिल्या स्क्रीनशॉटमधील प्रतिमा आहे. तुम्ही इतर फाइल्स आणि फोल्डर्स तिथे ठेवू शकता आणि ZeroHTTPd ने त्या स्टॅटिक फाइल्स कोणत्याही समस्यांशिवाय सर्व्ह केल्या पाहिजेत. जर ब्राउझरमधील पथ सार्वजनिक फोल्डरमधील पथाशी जुळत असेल, तर ZeroHTTPd या निर्देशिकेतील index.html फाइल शोधते. अतिथी पुस्तकासाठी सामग्री गतिशीलपणे व्युत्पन्न केली जाते. त्यात फक्त मुखपृष्ठ आहे, आणि त्याची सामग्री 'templates/guestbook/index.html' फाइलवर आधारित आहे. ZeroHTTPd विस्तारासाठी डायनॅमिक पृष्ठे सहज जोडते. कल्पना अशी आहे की वापरकर्ते या निर्देशिकेत टेम्पलेट जोडू शकतात आणि आवश्यकतेनुसार ZeroHTTPd वाढवू शकतात.

सर्व सात सर्व्हर तयार करण्यासाठी, चालवा make all उच्च-स्तरीय निर्देशिकेतून - आणि सर्व बिल्ड्स या निर्देशिकेत दिसतील. एक्झिक्युटेबल फाइल्स ज्या डिरेक्टरीमधून लॉन्च केल्या जातात त्या डिरेक्टरीमध्ये सार्वजनिक आणि टेम्पलेट्स डिरेक्टरी शोधतात.

लिनक्स API

या लेख मालिकेतील माहिती समजून घेण्यासाठी तुम्हाला Linux API मध्ये पारंगत असण्याची गरज नाही. तथापि, मी या विषयावर अधिक वाचण्याची शिफारस करतो; इंटरनेटवर अनेक संदर्भ संसाधने आहेत. जरी आम्ही Linux API च्या अनेक श्रेणींना स्पर्श करणार असलो तरी आमचे लक्ष प्रामुख्याने प्रक्रिया, थ्रेड्स, इव्हेंट्स आणि नेटवर्क स्टॅकवर असेल. लिनक्स API बद्दल पुस्तके आणि लेखांव्यतिरिक्त, मी सिस्टम कॉल्स आणि लायब्ररी फंक्शन्ससाठी वापरल्या जाणार्‍या माना वाचण्याची देखील शिफारस करतो.

कामगिरी आणि स्केलेबिलिटी

कार्यप्रदर्शन आणि स्केलेबिलिटी बद्दल एक टीप. सैद्धांतिकदृष्ट्या, त्यांच्यामध्ये कोणताही संबंध नाही. तुमच्याकडे अशी वेब सेवा असू शकते जी काही मिलिसेकंदांच्या प्रतिसाद वेळेसह खूप चांगली कार्य करते, परंतु ती अजिबात मोजत नाही. त्याचप्रमाणे, एक खराब कार्यप्रदर्शन करणारा वेब अनुप्रयोग असू शकतो ज्याला प्रतिसाद देण्यासाठी काही सेकंद लागतात, परंतु हजारो समवर्ती वापरकर्त्यांना हाताळण्यासाठी ते दहापटीने मोजले जाते. तथापि, उच्च कार्यक्षमता आणि स्केलेबिलिटीचे संयोजन हे एक अतिशय शक्तिशाली संयोजन आहे. उच्च-कार्यक्षमता ऍप्लिकेशन्स सामान्यतः संसाधनांचा कमी वापर करतात आणि अशा प्रकारे सर्व्हरवर अधिक समवर्ती वापरकर्त्यांना कार्यक्षमतेने सेवा देतात, खर्च कमी करतात.

CPU आणि I/O कार्ये

शेवटी, संगणनामध्ये नेहमी दोन संभाव्य प्रकारची कार्ये असतात: I/O आणि CPU साठी. इंटरनेटवरून विनंत्या प्राप्त करणे (नेटवर्क I/O), फाइल्स सर्व्ह करणे (नेटवर्क आणि डिस्क I/O), डेटाबेस (नेटवर्क आणि डिस्क I/O) शी संप्रेषण करणे या सर्व I/O क्रियाकलाप आहेत. काही डेटाबेस क्वेरी थोड्या CPU गहन असू शकतात (क्रमवारी लावणे, एक दशलक्ष परिणामांची सरासरी काढणे इ.). बहुतेक वेब ऍप्लिकेशन्स जास्तीत जास्त संभाव्य I/O द्वारे मर्यादित आहेत आणि प्रोसेसर क्वचितच पूर्ण क्षमतेने वापरला जातो. जेव्हा तुम्ही पाहता की काही I/O कार्य भरपूर CPU वापरत आहे, तेव्हा हे बहुधा खराब ऍप्लिकेशन आर्किटेक्चरचे लक्षण आहे. याचा अर्थ असा होऊ शकतो की CPU संसाधने प्रक्रिया व्यवस्थापन आणि संदर्भ स्विचिंगवर वाया जातात - आणि हे पूर्णपणे उपयुक्त नाही. जर तुम्ही इमेज प्रोसेसिंग, ऑडिओ फाइल कन्व्हर्जन किंवा मशीन लर्निंग सारखे काहीतरी करत असाल, तर अॅप्लिकेशनला शक्तिशाली CPU संसाधने आवश्यक आहेत. परंतु बहुतेक अनुप्रयोगांसाठी असे नाही.

सर्व्हर आर्किटेक्चरबद्दल अधिक जाणून घ्या

स्त्रोत: www.habr.com

लिनक्स नेटवर्क अनुप्रयोग कार्यप्रदर्शन. परिचय