ويب ايپليڪيشنون هاڻي هر جڳهه استعمال ڪيون ويون آهن، ۽ سڀني ٽرانسپورٽ پروٽوڪول جي وچ ۾، ايڇ ٽي ٽي پي جو حصو آهي. جڏهن ويب ايپليڪيشن ڊولپمينٽ جي نونسن جو مطالعو ڪيو، اڪثر ماڻهو آپريٽنگ سسٽم تي تمام گهٽ ڌيان ڏيندا آهن جتي اهي ايپليڪيشنون اصل ۾ هلن ٿيون. ترقي (Dev) ۽ آپريشنز (Ops) جي علحدگي صرف صورتحال کي خراب ڪري ڇڏيو. پر DevOps ڪلچر جي اڀار سان، ڊولپرز ڪلائوڊ ۾ پنهنجون ايپليڪيشنون هلائڻ جا ذميوار بڻجي رهيا آهن، تنهن ڪري اهو انهن لاءِ تمام ڪارائتو آهي ته هو آپريٽنگ سسٽم جي پسمنظر سان چڱيءَ طرح واقف ٿين. اهو خاص طور تي ڪارائتو آهي جيڪڏهن توهان ڪوشش ڪري رهيا آهيو هڪ سسٽم کي ترتيب ڏيڻ لاءِ هزارين يا ڏهه هزارين هڪ ئي وقت ۾ ڪنيڪشن.
ويب سروسز ۾ حدون تمام گهڻيون ساڳيون آهن جيڪي ٻين ايپليڪيشنن ۾ آهن. ڇا اهو لوڊ بيلنسرز يا ڊيٽابيس سرورز آهي، انهن سڀني ايپليڪيشنن کي اعلي ڪارڪردگي واري ماحول ۾ ساڳيو مسئلو آهي. انهن بنيادي حدن کي سمجهڻ ۽ عام طور تي انهن کي ڪيئن دور ڪجي توهان جي ويب ايپليڪيشنن جي ڪارڪردگي ۽ اسڪيبلٽي جو جائزو وٺڻ ۾ مدد ڪندي.
مان لکي رهيو آهيان مضمونن جو هي سلسلو نوجوان ڊولپرز جي سوالن جي جواب ۾ جيڪي بهتر ڄاڻ رکندڙ سسٽم آرڪيٽيڪٽس بڻجڻ چاهيندا آهن. اهو ناممڪن آهي واضح طور تي لينڪس ايپليڪيشن آپٽمائيزيشن ٽيڪنڪ کي سمجھڻ کان سواءِ بنيادي ڳالهين ۾ ته اهي ڪيئن ڪم ڪن ٿا آپريٽنگ سسٽم جي سطح تي. جيتوڻيڪ ايپليڪيشنن جا ڪيترائي قسم آهن، هن سلسلي ۾ مان چاهيان ٿو ويب بيڊ ايپليڪيشنن کي ڳولڻ بجاءِ ڊيسڪ ٽاپ ايپليڪيشنن جهڙوڪ برائوزر يا ٽيڪسٽ ايڊيٽر. ھي مواد ڊولپرز ۽ آرڪيٽيڪٽس لاءِ آھي جيڪي سمجھڻ چاھين ٿا ته لينڪس يا يونڪس پروگرام ڪيئن ڪم ڪن ٿا ۽ انھن کي اعليٰ ڪارڪردگيءَ لاءِ ڪيئن ٺاھيو وڃي.
لينڪس آهي سرور روم آپريٽنگ سسٽم، ۽ اڪثر ڪري توهان جون ايپليڪيشنون هن او ايس تي هلن ٿيون. جيتوڻيڪ مان چوان ٿو "لينڪس"، اڪثر وقت توهان محفوظ طور تي فرض ڪري سگهو ٿا ته منهنجو مطلب عام طور تي سڀني يونڪس جهڙو آپريٽنگ سسٽم. بهرحال، مون ٻين سسٽم تي گڏ ڪيل ڪوڊ کي آزمائي نه ڪيو آهي. تنهن ڪري، جيڪڏهن توهان FreeBSD يا OpenBSD ۾ دلچسپي رکو ٿا، توهان جا نتيجا مختلف ٿي سگهن ٿا. جڏهن مان ڪوشش ڪريان ٿو ڪجهه لينڪس-مخصوص، مان ان کي اشارو ڪريان ٿو.
جڏهن ته توهان هن علم کي استعمال ڪري سگهو ٿا شروع کان هڪ ايپ ٺاهڻ لاءِ ۽ اهو مڪمل طور تي بهتر ڪيو ويندو، اهو بهتر ناهي ته ائين نه ڪيو وڃي. جيڪڏهن توهان پنهنجي تنظيم جي ڪاروباري ايپليڪيشن لاءِ C يا C++ ۾ نئون ويب سرور لکو ٿا، اهو ٿي سگهي ٿو توهان جي نوڪري تي آخري ڏينهن. بهرحال، انهن ايپليڪيشنن جي جوڙجڪ کي ڄاڻڻ ۾ مدد ملندي موجوده پروگرامن کي چونڊڻ ۾. توهان پروسيس تي ٻڌل سسٽم جو مقابلو ڪرڻ جي قابل هوندا ٿريڊ تي ٻڌل سسٽم سان گڏو گڏ واقعن جي بنياد تي. توھان سمجھندا ۽ سمجھندا سين ڇو نينگڪس Apache httpd کان بھتر ڪم ڪري ٿو، ڇو ھڪڙو Tornado جي بنياد تي Python ايپليڪيشن وڌيڪ استعمال ڪندڙن جي خدمت ڪري سگھي ٿي Django جي بنياد تي Python ايپليڪيشن جي مقابلي ۾.
ZeroHTTPd: سکيا وارو اوزار
هڪ ويب سرور آهي جنهن کي مون شروع کان C ۾ هڪ تدريسي اوزار طور لکيو آهي. ان ۾ ڪوبه خارجي انحصار نه آهي، بشمول ريڊس تائين رسائي. اسان اسان جي پنهنجي Redis طريقا هلائيندا آهيون. وڌيڪ تفصيل لاءِ هيٺ ڏسو.
جيتوڻيڪ اسين ڊگھي نظريي تي بحث ڪري سگھون ٿا، ڪوڊ لکڻ، ان کي هلائڻ، ۽ سڀني سرور آرڪيٽيڪچرز کي ھڪ ٻئي سان ڀيٽڻ کان بھتر ڪجھ به نه آھي. اهو سڀ کان وڌيڪ واضح طريقو آهي. تنهن ڪري، اسان هر ماڊل کي استعمال ڪندي هڪ سادي ZeroHTTPd ويب سرور لکنداسين: پروسيس تي ٻڌل، موضوع تي ٻڌل، ۽ واقعي جي بنياد تي. اچو ته انهن مان هر هڪ سرور کي چيڪ ڪريو ۽ ڏسو ته اهي هڪ ٻئي جي مقابلي ۾ ڪيئن ڪم ڪن ٿا. ZeroHTTPd هڪ واحد C فائل ۾ لاڳو ڪيو ويو آهي. واقعي تي ٻڌل سرور شامل آهي ، هڪ عظيم هيش ٽيبل تي عمل درآمد جيڪو هڪ واحد هيڊر فائل ۾ اچي ٿو. ٻين حالتن ۾، ڪو به انحصار نه آهي، تنهنڪري منصوبي کي پيچيده نه ڪرڻ.
توھان کي سمجھڻ ۾ مدد لاءِ ڪوڊ ۾ ڪيترائي رايا آھن. ڪوڊ جي چند لائينن ۾ هڪ سادي ويب سرور هجڻ جي ڪري، ZeroHTTPd پڻ ويب ڊولپمينٽ لاءِ گهٽ ۾ گهٽ فريم ورڪ آهي. اهو محدود ڪارڪردگي آهي، پر جامد فائلن ۽ تمام سادو "متحرڪ" صفحن جي خدمت ڪرڻ جي قابل آهي. مون کي اهو چوڻ آهي ته ZeroHTTPd اعلي ڪارڪردگي لينڪس ايپليڪيشنون ٺاهڻ سکڻ لاء سٺو آهي. وڏي ۽ وڏي، گهڻيون ويب خدمتون درخواستن جو انتظار ڪن ٿيون، انهن کي چيڪ ڪريو ۽ انهن تي عمل ڪريو. اهو ئي آهي جيڪو ZeroHTTPd ڪندو. هي سکڻ جو هڪ اوزار آهي، نه پيداوار. اهو غلطي سنڀالڻ ۾ وڏو ناهي ۽ ممڪن ناهي ته بهترين حفاظتي عملن تي فخر ڪرڻ (او ها، مون استعمال ڪيو strcpy) يا سي ٻولي جون چالاڪ چالون. پر مون کي اميد آهي ته اهو پنهنجو ڪم سٺو ڪندو.
ZeroHTTPd هوم صفحو. اهو تصويرن سميت مختلف فائلن جي قسمن کي ڪڍي سگھي ٿو
مهمان ڪتاب جي درخواست
جديد ويب ايپليڪيشنون عام طور تي جامد فائلن تائين محدود نه آهن. انهن جو مختلف ڊيٽابيس، ڪيش وغيره سان پيچيده لاڳاپا آهن. ان ڪري اسان هڪ سادي ويب ايپليڪيشن ٺاهينداسين جنهن کي "گيسٽ بڪ" سڏيو ويندو آهي جتي سياح پنهنجي نالن سان داخلائون ڇڏيندا آهن. مهمان ڪتاب اسٽورن جون داخلائون اڳ ۾ ڇڏيل آهن. صفحي جي تري ۾ هڪ دورو ڪندڙ انسداد پڻ آهي.
ويب ايپليڪيشن "مهمان ڪتاب" ZeroHTTPd
ويزيٽر ڪائونٽر ۽ مهمانن جي ڪتاب جون داخلائون ريڊس ۾ محفوظ ٿيل آهن. Redis سان رابطي لاء، پنهنجا طريقا لاڳو ڪيا ويا آهن؛ اهي خارجي لائبريري تي منحصر نه آهن. مان هومبرو ڪوڊ کي رولنگ ڪرڻ جو وڏو پرستار نه آهيان جڏهن عوامي طور تي دستياب ۽ چڱي طرح آزمائشي حل موجود آهن. پر ZeroHTTPd جو مقصد لينڪس جي ڪارڪردگي جو مطالعو ڪرڻ ۽ خارجي خدمتن تائين رسائي آهي، جڏهن ته HTTP درخواستن جي خدمت ڪرڻ سان ڪارڪردگي جو هڪ سنگين اثر آهي. اسان کي اسان جي هر سرور آرڪيٽيڪچر ۾ ريڊس سان رابطي کي مڪمل طور تي ڪنٽرول ڪرڻ گهرجي. ڪجهه فن تعمير ۾ اسان بلاڪنگ ڪال استعمال ڪندا آهيون، ٻين ۾ اسان واقعي تي ٻڌل طريقا استعمال ڪندا آهيون. هڪ خارجي Redis ڪلائنٽ لائبريري استعمال ڪندي هي ڪنٽرول مهيا نه ڪندو. اضافي طور تي، اسان جو ننڍڙو ريڊس ڪلائنٽ صرف چند ڪم انجام ڏئي ٿو (حاصل ڪرڻ، ترتيب ڏيڻ، ۽ هڪ ڪني کي وڌائڻ؛ حاصل ڪرڻ ۽ هڪ صف ۾ شامل ڪرڻ). ان کان علاوه، ريڊس پروٽوڪول انتهائي خوبصورت ۽ سادو آهي. توهان کي ان کي خاص طور تي سکڻ جي ضرورت ناهي. بلڪل حقيقت اها آهي ته پروٽوڪول سڀ ڪم ڪري ٿو ڪوڊ جي اٽڪل سؤ لائنن ۾ اهو ڏيکاري ٿو ته اهو ڪيترو سٺو سوچيو ويو آهي.
هيٺ ڏنل انگ اکر ڏيکاري ٿو ته ايپليڪيشن ڇا ڪري ٿي جڏهن ڪلائنٽ (برائوزر) درخواست ڪري ٿو /guestbookURL.
مهمان ڪتاب ايپليڪيشن ڪيئن ڪم ڪري ٿي
جڏهن هڪ مهمان ڪتاب جو صفحو جاري ڪرڻ جي ضرورت آهي، اتي هڪ ڪال آهي فائيل سسٽم کي پڙهڻ لاءِ ٽيمپليٽ کي ميموري ۾ ۽ ٽي نيٽ ورڪ ڪالون Redis ڏانهن. ٽيمپليٽ فائل مٿي ڏنل اسڪرين شاٽ ۾ صفحي لاءِ اڪثر HTML مواد تي مشتمل آهي. مواد جي متحرڪ حصي لاءِ خاص جڳه دار پڻ آھن: پوسٽون ۽ دورو ڪندڙ انسداد. اسان انهن کي Redis کان وصول ڪندا آهيون، انهن کي صفحي ۾ داخل ڪريو ۽ ڪلائنٽ کي مڪمل طور تي ٺهيل مواد سان مهيا ڪريو. Redis ڏانهن ٽيون ڪال کان بچي سگهجي ٿو ڇاڪاڻ ته ريڊس نئين ڪيئي قيمت کي واپس آڻيندو آهي جڏهن وڌايو ويندو آهي. تنهن هوندي، اسان جي سرور لاءِ، جنهن وٽ هڪ هم وقت ساز واقعن تي ٻڌل فن تعمير آهي، ڪيترائي نيٽ ورڪ ڪالون سکيا جي مقصدن لاءِ سٺو امتحان آهن. تنهن ڪري اسان ريڊس واپسي جي قيمت کي رد ڪريون ٿا سياحن جي تعداد جي ۽ ان کي الڳ ڪال سان پڇو.
سرور آرڪيٽيڪچرز ZeroHTTPd
اسان ZeroHTTPd جا ست ورجن ٺاهي رهيا آهيون ساڳئي ڪارڪردگي سان پر مختلف فن تعمير:
- ورجائيندڙ
- فورڪ سرور (هڪ ٻار جو عمل في درخواست)
- پري-فورڪ سرور (پري-فورڪنگ پروسيسز)
- سرور تي عملدرآمد جي سلسلي سان (هڪ سلسلي في درخواست)
- سرور کان اڳ ٺاھڻ سان
- فن تعمير جي بنياد تي
poll() - فن تعمير جي بنياد تي
epoll
اسان هر فن تعمير جي ڪارڪردگي کي ماپ ڪريون ٿا سرور لوڊ ڪندي HTTP درخواستن سان. پر جڏهن انتهائي متوازي فن تعمير جي مقابلي ۾، سوالن جو تعداد وڌائي ٿو. اسان ٽي ڀيرا آزمايو ۽ سراسري حساب ڪريو.
جاچ جو طريقو
ZeroHTTPd لوڊ ٽيسٽنگ سيٽ اپ
اهو ضروري آهي ته ٽيسٽ هلائڻ دوران، سڀئي جزا ساڳي مشين تي نه هلن. انهي صورت ۾، او ايس اضافي شيڊولنگ اوور هيڊ کي شامل ڪري ٿو جيئن اجزاء سي پي يو لاء مقابلو ڪن ٿا. آپريٽنگ سسٽم کي ماپڻ هر هڪ چونڊيل سرور آرڪيٽيڪچرز جي مٿان هيڊ هن مشق جي اهم مقصدن مان هڪ آهي. وڌيڪ متغير شامل ڪرڻ عمل لاءِ نقصانڪار ٿي ويندا. تنهن ڪري، مٿي ڏنل تصوير ۾ سيٽنگ بهترين ڪم ڪري ٿي.
انهن مان هر هڪ سرور ڇا ڪندو آهي؟
- load.unixism.net: هي اهو آهي جتي اسان هلون ٿا
ab, Apache Benchmark افاديت. اهو اسان جي سرور آرڪيٽيڪچر کي جانچڻ لاءِ گهربل لوڊ ٺاهي ٿو. - nginx.unixism.net: ڪڏهن ڪڏهن اسين سرور پروگرام جا هڪ کان وڌيڪ مثال هلائڻ چاهيون ٿا. هن کي ڪرڻ لاء، نينگڪس سرور مناسب سيٽنگن سان ڪم ڪري ٿو لوڊ بيلنسر جي طور تي اچي رهيو آهي ab اسان جي سرور جي عملن ڏانهن.
- zerohttpd.unixism.net: هتي اسان پنهنجي سرور پروگرامن کي ست مختلف آرڪيٽيڪچرز تي هلائيندا آهيون، هڪ وقت ۾.
- redis.unixism.net: هي سرور ريڊس ڊيمن کي هلائي ٿو، جتي گيسٽ بڪ جون داخلائون ۽ وزيٽر ڪائونٽر محفوظ ٿيل آهن.
سڀئي سرور ساڳيا پروسيسر ڪور تي هلندا آهن. اهو خيال هر فن تعمير جي وڌ ۾ وڌ ڪارڪردگي جو جائزو وٺڻ آهي. جيئن ته سڀئي سرور پروگرام ساڳيا هارڊويئر تي آزمايا ويا آهن، اهو مقابلو لاء هڪ بنيادي آهي. منهنجو ٽيسٽ سيٽ اپ ڊجيٽل سمنڊ مان ڪرائي تي ورچوئل سرورز تي مشتمل آهي.
اسان ڇا ماپي رهيا آهيون؟
توھان مختلف اشارن کي ماپ ڪري سگھو ٿا. اسان هر فن تعمير جي ڪارڪردگي جو جائزو وٺون ٿا ڏنل ترتيب ۾ سرورز کي لوڊ ڪندي مختلف سطحن تي درخواستن سان: لوڊ وڌندو 20 کان 15 سمورو استعمال ڪندڙ.
جاچ جا نتيجا
هيٺ ڏنل چارٽ ڏيکاري ٿو سرور جي ڪارڪردگي مختلف فن تعمير تي متوازي جي مختلف سطحن تي. y-محور في سيڪنڊ درخواستن جو تعداد آھي، x-محور متوازي ڪنيڪشن آھي.
ھيٺ ڏنل جدول آھي نتيجن سان.
درخواستون في سيڪنڊ
متوازنيت
ورجائيندڙ
ڪانٽو
اڳي ڪانٽو
اسٽريمنگ
پري اسٽريمنگ
راء
ايپل
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،000
-
-
وڏي پکيڙ
-
2200
-
2200
11،000
-
-
-
-
2200
-
2122
12،000
-
-
-
-
970
-
1958
13،000
-
-
-
-
730
-
1897
14،000
-
-
-
-
590
-
1466
15،000
-
-
-
-
532
-
1281
گراف ۽ ٽيبل مان اهو ڏسي سگهجي ٿو ته 8000 کان مٿي هڪ ئي وقت جي درخواستن ۾ اسان وٽ صرف ٻه رانديگر بچيا آهن: پري فورڪ ۽ ايپول. جيئن ته لوڊ وڌندو آهي، هڪ پول تي ٻڌل سرور هڪ اسٽريمنگ کان بدتر انجام ڏئي ٿو. ٿريڊ کان اڳ ٺاھڻ وارو فن تعمير ايپول لاءِ ھڪڙو قابل مقابلو آھي، ھڪڙو ثبوت آھي ته لينڪس ڪنيل ڪيترين ئي موضوعن جي وڏي تعداد کي شيڊول ڪري ٿو.
ZeroHTTPd ماخذ ڪوڊ
ZeroHTTPd ماخذ ڪوڊ . هر فن تعمير لاءِ الڳ ڊاريڪٽري آهي.
ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── main.c ├── 03_preforking ├── main.c ├── 04_preforking 05_ ٿريڊنگ │ ├── main.c ├── 06_پري ٿريڊنگ │ ├── main.c ├── 07_poll │ ├── main.c ├── XNUMX_epoll │ ├─── main.c ├ عوامي├── main.c ├── انڊيڪس .html │ └── ٽڪس png └── ٽيمپليٽ └── مهمانن جو ڪتاب └── index.html
سڀني آرڪيٽيڪچرز لاءِ ستن ڊائريڪٽرن کان علاوه، مٿين سطح جي ڊاريڪٽري ۾ ٻه وڌيڪ آهن: عوامي ۽ ٽيمپليٽس. پهرين ۾ index.html فائل ۽ پهرين اسڪرين شاٽ جي تصوير شامل آهي. توهان اتي رکي سگهو ٿا ٻيون فائلون ۽ فولڊر، ۽ ZeroHTTPd انهن جامد فائلن کي بغير ڪنهن مسئلن جي خدمت ڪرڻ گهرجي. جيڪڏهن برائوزر ۾ رستو عوامي فولڊر ۾ رستي سان ملندو آهي، پوء ZeroHTTPd هن ڊاريڪٽري ۾ index.html فائل ڳولي ٿو. مھمانن جي ڪتاب لاءِ مواد متحرڪ طور تي ٺاھيو ويو آھي. اهو صرف هڪ هوم صفحو آهي، ۽ ان جو مواد فائيل 'templates/guestbook/index.html' تي ٻڌل آهي. ZeroHTTPd آساني سان متحرڪ صفحا شامل ڪري ٿو واڌ لاءِ. خيال اهو آهي ته صارف هن ڊاريڪٽري ۾ ٽيمپليٽ شامل ڪري سگهن ٿا ۽ ضرورت مطابق ZeroHTTPd کي وڌايو.
سڀني ستن سرورن کي ٺاهڻ لاء، هلائي make all مٿين سطح جي ڊاريڪٽري مان - ۽ سڀ تعميرات هن ڊاريڪٽري ۾ ظاهر ٿيندا. Executable فائلون ڊاريڪٽري ۾ عوام ۽ ٽيمپليٽ ڊائريڪٽرن کي ڳوليندا آهن جتان اهي شروع ڪيا ويا آهن.
لينڪس API
هن آرٽيڪل سيريز ۾ معلومات کي سمجهڻ لاءِ توهان کي لينڪس API ۾ چڱي طرح واقف ٿيڻ جي ضرورت ناهي. بهرحال، مان هن موضوع تي وڌيڪ پڙهڻ جي صلاح ڏيان ٿو؛ انٽرنيٽ تي ڪيترائي حوالا وسيلا آهن. جيتوڻيڪ اسان لينڪس APIs جي ڪيترن ئي قسمن تي رابطو ڪنداسين، اسان جو ڌيان بنيادي طور تي پروسيس، موضوعن، واقعن، ۽ نيٽورڪ اسٽيڪ تي هوندو. لينڪس API بابت ڪتابن ۽ مضمونن کان علاوه، مان پڻ پڙهڻ جي سفارش ڪريان ٿو مانا سسٽم ڪالن ۽ لائبريري ڪمن لاءِ استعمال ٿيل.
ڪارڪردگي ۽ اسڪاليبلٽي
ڪارڪردگي ۽ اسپيبلبل بابت هڪ نوٽ. نظرياتي طور تي، انهن جي وچ ۾ ڪوبه تعلق نه آهي. توھان وٽ ھڪڙي ويب سروس آھي جيڪا تمام سٺي ڪم ڪري ٿي، ڪجھ ملي سيڪنڊن جي جوابي وقت سان، پر اھو ڪجھ به ماپ نٿو ڪري. ساڳيءَ طرح، ٿي سگهي ٿو هڪ خراب ڪارڪردگيءَ واري ويب ايپليڪيشن جيڪا جواب ڏيڻ ۾ چند سيڪنڊن جو وقت وٺي، پر اهو ڏهن هزارن سان گڏ استعمال ڪندڙن کي سنڀالڻ لاءِ ڏهن جي ماپ ڪري ٿو. جڏهن ته، اعلي ڪارڪردگي ۽ اسڪالبل جو ميلاپ هڪ تمام طاقتور ميلاپ آهي. اعليٰ ڪارڪردگي واريون ايپليڪيشنون عام طور تي وسيلن کي گھٽ استعمال ڪنديون آهن ۽ اهڙيءَ طرح موثر طريقي سان سرور تي وڌيڪ سمورو استعمال ڪندڙن جي خدمت ڪندي، خرچن کي گھٽائڻ.
CPU ۽ I/O ڪم
آخرڪار، ڪمپيوٽنگ ۾ هميشه ٻه ممڪن قسم جا ڪم آهن: I/O ۽ CPU لاءِ. انٽرنيٽ تي درخواستون وصول ڪرڻ (نيٽ ورڪ I/O)، فائلون مهيا ڪرڻ (نيٽ ورڪ ۽ ڊسڪ I/O)، ڊيٽابيس سان رابطو ڪرڻ (نيٽ ورڪ ۽ ڊسڪ I/O) سڀ I/O سرگرميون آهن. ڪجھ ڊيٽابيس جا سوال ٿورڙا سي پي يو ٿي سگھن ٿا (ترتيب ڪرڻ، ھڪ ملين نتيجن جي اوسط، وغيره). گهڻيون ويب ايپليڪيشنون وڌ کان وڌ ممڪن I/O تائين محدود هونديون آهن، ۽ پروسيسر تمام گهٽ استعمال ڪيو ويندو آهي مڪمل گنجائش تي. جڏهن توهان ڏسندا آهيو ته ڪجهه I/O ڪم تمام گهڻو سي پي يو استعمال ڪري رهيو آهي، اهو گهڻو ڪري ناقص ايپليڪيشن آرڪيٽيڪچر جي نشاني آهي. ان جو مطلب اهو ٿي سگھي ٿو ته سي پي يو وسيلن کي پروسيس مينيجمينٽ ۽ حوالن جي سوئچنگ تي ضايع ڪيو ويو آهي - ۽ اهو مڪمل طور تي مفيد ناهي. جيڪڏھن توھان ڪجھ ڪري رھيا آھيو تصوير پروسيسنگ، آڊيو فائل ڪنورشن، يا مشين لرننگ، پوءِ ايپليڪيشن کي طاقتور سي پي يو وسيلن جي ضرورت آھي. پر اڪثر ايپليڪيشنن لاءِ اهو معاملو ناهي.
سرور آرڪيٽيڪچر بابت وڌيڪ ڄاڻو
جو ذريعو: www.habr.com