ویب ایپلیکیشنز اب ہر جگہ استعمال ہوتی ہیں، اور تمام ٹرانسپورٹ پروٹوکولز میں، HTTP کا بڑا حصہ ہے۔ ویب ایپلیکیشن ڈویلپمنٹ کی باریکیوں کا مطالعہ کرتے وقت، زیادہ تر لوگ آپریٹنگ سسٹم پر بہت کم توجہ دیتے ہیں جہاں یہ ایپلی کیشنز درحقیقت چلتی ہیں۔ ترقی (Dev) اور آپریشنز (Ops) کی علیحدگی نے صورتحال کو مزید خراب کیا۔ لیکن DevOps کلچر کے عروج کے ساتھ، ڈیولپرز اپنی ایپلیکیشنز کو کلاؤڈ میں چلانے کے لیے ذمہ دار بن رہے ہیں، اس لیے آپریٹنگ سسٹم کے بیک اینڈ سے اچھی طرح واقف ہونا ان کے لیے بہت مفید ہے۔ یہ خاص طور پر مفید ہے اگر آپ ہزاروں یا دسیوں ہزار بیک وقت کنکشن کے لیے ایک سسٹم کو تعینات کرنے کی کوشش کر رہے ہیں۔
ویب سروسز کی حدود دیگر ایپلی کیشنز سے بہت ملتی جلتی ہیں۔ چاہے یہ لوڈ بیلنسرز ہوں یا ڈیٹا بیس سرورز، ان تمام ایپلی کیشنز میں اعلی کارکردگی والے ماحول میں ایک جیسے مسائل ہیں۔ ان بنیادی حدود کو سمجھنا اور عام طور پر ان پر کیسے قابو پایا جائے آپ کو اپنی ویب ایپلیکیشنز کی کارکردگی اور اسکیل ایبلٹی کا اندازہ لگانے میں مدد ملے گی۔
میں مضامین کا یہ سلسلہ ان نوجوان ڈویلپرز کے سوالات کے جواب میں لکھ رہا ہوں جو اچھی طرح سے باخبر سسٹم آرکیٹیکٹس بننا چاہتے ہیں۔ آپریٹنگ سسٹم کی سطح پر وہ کس طرح کام کرتے ہیں اس کی بنیادی باتوں میں غوطے لگائے بغیر لینکس ایپلیکیشن آپٹیمائزیشن کی تکنیک کو واضح طور پر سمجھنا ناممکن ہے۔ اگرچہ ایپلی کیشنز کی بہت سی قسمیں ہیں، اس سلسلے میں میں ڈیسک ٹاپ ایپلی کیشنز جیسے براؤزر یا ٹیکسٹ ایڈیٹر کے بجائے ویب پر مبنی ایپلی کیشنز کو تلاش کرنا چاہتا ہوں۔ یہ مواد ان ڈویلپرز اور آرکیٹیکٹس کے لیے ہے جو یہ سمجھنا چاہتے ہیں کہ لینکس یا یونکس پروگرام کیسے کام کرتے ہیں اور اعلی کارکردگی کے لیے ان کی ساخت کیسے بنائی جاتی ہے۔
لینکس ہے۔ سرور روم آپریٹنگ سسٹم، اور اکثر آپ کی ایپلی کیشنز اس OS پر چلتی ہیں۔ اگرچہ میں "لینکس" کہتا ہوں، زیادہ تر وقت آپ محفوظ طریقے سے یہ فرض کر سکتے ہیں کہ میرا مطلب عام طور پر تمام یونکس جیسے آپریٹنگ سسٹم سے ہے۔ تاہم، میں نے دوسرے سسٹمز پر ساتھ والے کوڈ کا تجربہ نہیں کیا ہے۔ لہذا، اگر آپ FreeBSD یا OpenBSD میں دلچسپی رکھتے ہیں، تو آپ کے نتائج مختلف ہو سکتے ہیں۔ جب میں لینکس سے متعلق کچھ کرنے کی کوشش کرتا ہوں تو میں اس کی نشاندہی کرتا ہوں۔
اگرچہ آپ اس علم کو شروع سے ایک ایپ بنانے کے لیے استعمال کر سکتے ہیں اور یہ بالکل بہتر ہو جائے گا، ایسا نہ کرنا ہی بہتر ہے۔ اگر آپ اپنی تنظیم کی کاروباری ایپلیکیشن کے لیے C یا C++ میں نیا ویب سرور لکھتے ہیں، تو یہ آپ کا کام کا آخری دن ہو سکتا ہے۔ تاہم، ان ایپلی کیشنز کی ساخت کو جاننے سے موجودہ پروگراموں کو منتخب کرنے میں مدد ملے گی۔ آپ پروسیس پر مبنی سسٹمز کا تھریڈ پر مبنی سسٹمز کے ساتھ ساتھ ایونٹ پر مبنی سسٹمز کا موازنہ کر سکیں گے۔ آپ سمجھیں گے اور تعریف کریں گے کہ کیوں Nginx اپاچی httpd سے بہتر کارکردگی کا مظاہرہ کرتا ہے، کیوں ٹورنیڈو پر مبنی پائتھون ایپلی کیشن Django پر مبنی Python ایپلی کیشن کے مقابلے زیادہ صارفین کی خدمت کر سکتی ہے۔
ZeroHTTPd: سیکھنے کا آلہ
ایک ویب سرور ہے جسے میں نے شروع سے C میں بطور تدریسی ٹول لکھا ہے۔ اس کا کوئی بیرونی انحصار نہیں ہے، بشمول Redis تک رسائی۔ ہم اپنے Redis طریقہ کار چلاتے ہیں۔ مزید تفصیلات کے لیے نیچے دیکھیں۔
اگرچہ ہم تھیوری پر طویل بحث کر سکتے ہیں، لیکن کوڈ لکھنے، اسے چلانے، اور تمام سرور آرکیٹیکچرز کا ایک دوسرے سے موازنہ کرنے سے بہتر کوئی چیز نہیں ہے۔ یہ سب سے واضح طریقہ ہے۔ لہذا، ہم ہر ماڈل کا استعمال کرتے ہوئے ایک سادہ ZeroHTTPd ویب سرور لکھیں گے: عمل پر مبنی، تھریڈ پر مبنی، اور ایونٹ پر مبنی۔ آئیے ان سرورز میں سے ہر ایک کو چیک کریں اور دیکھیں کہ وہ ایک دوسرے کے مقابلے میں کیسا کارکردگی کا مظاہرہ کرتے ہیں۔ ZeroHTTPd ایک واحد C فائل میں لاگو کیا جاتا ہے۔ ایونٹ پر مبنی سرور شامل ہے۔ ، ایک زبردست ہیش ٹیبل کا نفاذ جو ایک ہیڈر فائل میں آتا ہے۔ دوسرے معاملات میں، کوئی انحصار نہیں ہے، تاکہ منصوبے کو پیچیدہ نہ بنایا جائے۔
آپ کو سمجھنے میں مدد کے لیے کوڈ میں بہت سارے تبصرے ہیں۔ کوڈ کی چند لائنوں میں ایک سادہ ویب سرور ہونے کے ناطے، ZeroHTTPd ویب ڈویلپمنٹ کے لیے ایک کم سے کم فریم ورک بھی ہے۔ اس کی فعالیت محدود ہے، لیکن یہ جامد فائلوں اور بہت آسان "متحرک" صفحات پیش کرنے کے قابل ہے۔ مجھے یہ کہنا ہے کہ ZeroHTTPd اعلی کارکردگی والے لینکس ایپلی کیشنز کو بنانے کا طریقہ سیکھنے کے لیے اچھا ہے۔ بڑے پیمانے پر، زیادہ تر ویب سروسز درخواستوں کا انتظار کرتی ہیں، انہیں چیک کرتی ہیں اور ان پر کارروائی کرتی ہیں۔ بالکل وہی ہے جو ZeroHTTPd کرے گا۔ یہ سیکھنے کا آلہ ہے، پیداوار نہیں۔ غلطی سے نمٹنے میں یہ بہت اچھا نہیں ہے اور اس سے بہترین حفاظتی طریقوں پر فخر کرنے کا امکان نہیں ہے (اوہ ہاں، میں نے استعمال کیا strcpy) یا C زبان کی ہوشیار چالیں۔ لیکن مجھے امید ہے کہ یہ اپنا کام بخوبی انجام دے گی۔
ZeroHTTPd ہوم پیج۔ یہ تصاویر سمیت مختلف فائل کی اقسام کو آؤٹ پٹ کر سکتا ہے۔
مہمانوں کی کتاب کی درخواست
جدید ویب ایپلیکیشنز عام طور پر جامد فائلوں تک محدود نہیں ہیں۔ وہ مختلف ڈیٹا بیسز، کیشز وغیرہ کے ساتھ پیچیدہ تعاملات رکھتے ہیں۔ اس لیے ہم "گیسٹ بک" کے نام سے ایک سادہ ویب ایپلیکیشن بنائیں گے جہاں زائرین اپنے ناموں سے اندراجات چھوڑتے ہیں۔ مہمانوں کی کتابوں کے اندراجات پہلے باقی رہ گئے ہیں۔ صفحہ کے نیچے ایک وزیٹر کاؤنٹر بھی ہے۔
ویب ایپلیکیشن "گیسٹ بک" ZeroHTTPd
وزیٹر کاؤنٹر اور مہمانوں کی کتابوں کے اندراجات Redis میں محفوظ ہیں۔ Redis کے ساتھ رابطے کے لیے، اپنے طریقہ کار کو لاگو کیا جاتا ہے؛ وہ بیرونی لائبریری پر انحصار نہیں کرتے ہیں۔ جب عوامی طور پر دستیاب اور اچھی طرح سے تجربہ شدہ حل موجود ہوں تو میں ہومبرو کوڈ کو رول آؤٹ کرنے کا بڑا پرستار نہیں ہوں۔ لیکن زیرو ایچ ٹی ٹی پی ڈی کا مقصد لینکس کی کارکردگی اور بیرونی خدمات تک رسائی کا مطالعہ کرنا ہے، جبکہ ایچ ٹی ٹی پی کی درخواستیں پیش کرنے سے کارکردگی پر سنگین اثر پڑتا ہے۔ ہمیں اپنے ہر سرور کے فن تعمیر میں Redis کے ساتھ مواصلات کو مکمل طور پر کنٹرول کرنا چاہیے۔ کچھ فن تعمیر میں ہم بلاکنگ کالز کا استعمال کرتے ہیں، دوسروں میں ہم ایونٹ پر مبنی طریقہ کار استعمال کرتے ہیں۔ بیرونی Redis کلائنٹ لائبریری کا استعمال یہ کنٹرول فراہم نہیں کرے گا۔ مزید برآں، ہمارا چھوٹا Redis کلائنٹ صرف چند افعال انجام دیتا ہے (کسی کلید کو حاصل کرنا، ترتیب دینا اور ان میں اضافہ کرنا؛ حاصل کرنا اور اس میں شامل کرنا)۔ اس کے علاوہ، Redis پروٹوکول انتہائی خوبصورت اور سادہ ہے۔ آپ کو اسے خاص طور پر سکھانے کی بھی ضرورت نہیں ہے۔ حقیقت یہ ہے کہ پروٹوکول تمام کام کوڈ کی تقریباً ایک سو لائنوں میں کرتا ہے یہ ظاہر کرتا ہے کہ یہ کتنا سوچا سمجھا ہے۔
درج ذیل اعداد و شمار سے پتہ چلتا ہے کہ جب کلائنٹ (براؤزر) درخواست کرتا ہے تو ایپلیکیشن کیا کرتی ہے۔ /guestbookURL.
مہمانوں کی کتاب کی درخواست کیسے کام کرتی ہے۔
جب گیسٹ بک پیج کو جاری کرنے کی ضرورت ہوتی ہے تو، فائل سسٹم کو میموری میں ٹیمپلیٹ پڑھنے کے لیے ایک کال اور Redis کو تین نیٹ ورک کالز ہوتی ہیں۔ ٹیمپلیٹ فائل مندرجہ بالا اسکرین شاٹ میں صفحہ کے لیے زیادہ تر HTML مواد پر مشتمل ہے۔ مواد کے متحرک حصے کے لیے خصوصی پلیس ہولڈرز بھی ہیں: پوسٹس اور وزیٹر کاؤنٹر۔ ہم انہیں Redis سے وصول کرتے ہیں، انہیں صفحہ میں داخل کرتے ہیں اور کلائنٹ کو مکمل طور پر تشکیل شدہ مواد فراہم کرتے ہیں۔ Redis کو تیسری کال سے بچا جا سکتا ہے کیونکہ Redis اضافہ ہونے پر نئی کلیدی قدر لوٹاتا ہے۔ تاہم، ہمارے سرور کے لیے، جس میں ایک غیر مطابقت پذیر ایونٹ پر مبنی فن تعمیر ہے، بہت ساری نیٹ ورک کالیں سیکھنے کے مقاصد کے لیے ایک اچھا امتحان ہیں۔ لہذا ہم وزٹرز کی تعداد کی Redis کی واپسی کی قیمت کو مسترد کرتے ہیں اور اس سے الگ کال کے ساتھ استفسار کرتے ہیں۔
سرور آرکیٹیکچرز زیرو ایچ ٹی ٹی پی ڈی
ہم ZeroHTTPd کے سات ورژن اسی فعالیت کے ساتھ بنا رہے ہیں لیکن مختلف فن تعمیرات:
- تکراری
- فورک سرور (ایک بچہ عمل فی درخواست)
- پری فورک سرور (عمل کی پری فورکنگ)
- ایگزیکیوشن تھریڈز والا سرور (فی درخواست ایک تھریڈ)
- پری تھریڈ تخلیق کے ساتھ سرور
- فن تعمیر پر مبنی
poll() - فن تعمیر پر مبنی
epoll
ہم HTTP درخواستوں کے ساتھ سرور کو لوڈ کرکے ہر فن تعمیر کی کارکردگی کی پیمائش کرتے ہیں۔ لیکن جب انتہائی متوازی فن تعمیر کا موازنہ کیا جائے تو سوالات کی تعداد بڑھ جاتی ہے۔ ہم تین بار ٹیسٹ کرتے ہیں اور اوسط کا حساب لگاتے ہیں۔
جانچ کا طریقہ کار
ZeroHTTPd لوڈ ٹیسٹنگ سیٹ اپ
یہ ضروری ہے کہ ٹیسٹ چلاتے وقت، تمام اجزاء ایک ہی مشین پر نہ چلیں۔ اس صورت میں، OS کو اضافی شیڈولنگ اوور ہیڈ کا سامنا کرنا پڑتا ہے کیونکہ اجزاء CPU کے لیے مقابلہ کرتے ہیں۔ ہر منتخب سرور فن تعمیر کے آپریٹنگ سسٹم کی اوور ہیڈ کی پیمائش کرنا اس مشق کے اہم ترین مقاصد میں سے ایک ہے۔ مزید متغیرات کو شامل کرنا اس عمل کے لیے نقصان دہ ہو جائے گا۔ لہذا، اوپر تصویر میں ترتیب بہترین کام کرتا ہے.
ان میں سے ہر ایک سرور کیا کرتا ہے؟
- load.unixism.net: یہ وہ جگہ ہے جہاں ہم چلتے ہیں۔
ab، اپاچی بینچ مارک افادیت۔ یہ ہمارے سرور کے فن تعمیر کو جانچنے کے لیے درکار بوجھ پیدا کرتا ہے۔ - nginx.unixism.net: بعض اوقات ہم سرور پروگرام کی ایک سے زیادہ مثالیں چلانا چاہتے ہیں۔ ایسا کرنے کے لیے، مناسب ترتیبات کے ساتھ Nginx سرور آنے والے لوڈ بیلنس کے طور پر کام کرتا ہے۔ ab ہمارے سرور کے عمل میں۔
- zerohttpd.unixism.net: یہاں ہم سات مختلف فن تعمیر پر اپنے سرور پروگرام چلاتے ہیں، ایک وقت میں ایک۔
- redis.unixism.net: یہ سرور Redis ڈیمون چلاتا ہے، جہاں گیسٹ بک کے اندراجات اور وزیٹر کاؤنٹرز کو محفوظ کیا جاتا ہے۔
تمام سرورز ایک ہی پروسیسر کور پر چلتے ہیں۔ خیال یہ ہے کہ ہر فن تعمیر کی زیادہ سے زیادہ کارکردگی کا جائزہ لیا جائے۔ چونکہ تمام سرور پروگراموں کو ایک ہی ہارڈویئر پر ٹیسٹ کیا جاتا ہے، یہ موازنہ کے لیے ایک بنیادی لائن ہے۔ میرا ٹیسٹ سیٹ اپ ڈیجیٹل اوشین سے کرائے پر لیے گئے ورچوئل سرورز پر مشتمل ہے۔
ہم کیا پیمائش کر رہے ہیں؟
آپ مختلف اشارے کی پیمائش کر سکتے ہیں۔ ہم متوازی کی مختلف سطحوں پر درخواستوں کے ساتھ سرورز کو لوڈ کر کے ایک دی گئی ترتیب میں ہر فن تعمیر کی کارکردگی کا جائزہ لیتے ہیں: بوجھ 20 سے 15 ہم آہنگ صارفین تک بڑھتا ہے۔
ٹیسٹ کے نتائج
مندرجہ ذیل چارٹ متوازی کی مختلف سطحوں پر مختلف فن تعمیرات پر سرورز کی کارکردگی کو ظاہر کرتا ہے۔ y-axis فی سیکنڈ درخواستوں کی تعداد ہے، x-axis متوازی کنکشن ہے۔
ذیل میں نتائج کے ساتھ ایک جدول ہے۔
فی سیکنڈ کی درخواستیں
اتفاق
تکراری
کانٹا
پری فورک
سلسلہ بندی
پری اسٹریمنگ
سروے
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،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 │ ├── 01_iterative │ ├── main.c ├── 02_فورکنگ │ ├── main.c ├── main.c ├── 03_preforking ├── main. 04_ تھریڈنگ │ ├── main.c ├── 05_پری تھریڈنگ │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ │ └── main.c ├├─ عوامی بنائیں ├── انڈیکس .html │ └── ٹکس png └── ٹیمپلیٹس └── گیسٹ بک └── index.html
تمام آرکیٹیکچرز کے لیے سات ڈائریکٹریوں کے علاوہ، اعلیٰ سطحی ڈائرکٹری میں دو اور ہیں: عوامی اور ٹیمپلیٹس۔ پہلے میں index.html فائل اور پہلے اسکرین شاٹ کی تصویر شامل ہے۔ آپ وہاں دوسری فائلیں اور فولڈر رکھ سکتے ہیں، اور ZeroHTTPd کو ان جامد فائلوں کو بغیر کسی پریشانی کے پیش کرنا چاہیے۔ اگر براؤزر کا راستہ عوامی فولڈر کے راستے سے ملتا ہے، تو ZeroHTTPd اس ڈائریکٹری میں index.html فائل کو تلاش کرتا ہے۔ مہمانوں کی کتاب کا مواد متحرک طور پر تیار کیا جاتا ہے۔ اس کا صرف ہوم پیج ہے، اور اس کا مواد فائل 'templates/guestbook/index.html' پر مبنی ہے۔ ZeroHTTPd آسانی سے توسیع کے لیے متحرک صفحات شامل کرتا ہے۔ خیال یہ ہے کہ صارف اس ڈائریکٹری میں ٹیمپلیٹس شامل کر سکتے ہیں اور ضرورت کے مطابق زیرو ایچ ٹی ٹی پی ڈی کو بڑھا سکتے ہیں۔
تمام سات سرورز بنانے کے لیے، چلائیں۔ make all ٹاپ لیول ڈائرکٹری سے - اور تمام بلڈ اس ڈائرکٹری میں ظاہر ہوں گے۔ ایگزیکیوٹیبل فائلیں اس ڈائرکٹری میں پبلک اور ٹیمپلیٹس ڈائرکٹریز کو تلاش کرتی ہیں جہاں سے وہ لانچ کی جاتی ہیں۔
لینکس API
اس مضمون کی سیریز میں معلومات کو سمجھنے کے لیے آپ کو لینکس API میں مہارت حاصل کرنے کی ضرورت نہیں ہے۔ تاہم، میں اس موضوع پر مزید پڑھنے کا مشورہ دیتا ہوں؛ انٹرنیٹ پر بہت سے حوالہ جات موجود ہیں۔ اگرچہ ہم لینکس APIs کے کئی زمروں کو چھوئیں گے، ہماری توجہ بنیادی طور پر عمل، دھاگوں، واقعات، اور نیٹ ورک اسٹیک پر ہوگی۔ لینکس API کے بارے میں کتابوں اور مضامین کے علاوہ، میں استعمال شدہ سسٹم کالز اور لائبریری فنکشنز کے لیے مانا پڑھنے کی بھی سفارش کرتا ہوں۔
کارکردگی اور اسکیل ایبلٹی
کارکردگی اور توسیع پذیری کے بارے میں ایک نوٹ۔ نظریاتی طور پر، ان کے درمیان کوئی تعلق نہیں ہے. آپ کے پاس ایک ایسی ویب سروس ہو سکتی ہے جو بہت اچھی طرح سے کام کرتی ہے، جوابی وقت کے ساتھ چند ملی سیکنڈز، لیکن یہ بالکل بھی پیمانہ نہیں ہے۔ اسی طرح، ایک ناقص کارکردگی کا مظاہرہ کرنے والی ویب ایپلیکیشن ہو سکتی ہے جس کا جواب دینے میں چند سیکنڈ لگتے ہیں، لیکن یہ دسیوں ہزار کے ساتھ ساتھ صارفین کو سنبھالنے کے لیے دسیوں کا پیمانہ بناتا ہے۔ تاہم، اعلی کارکردگی اور اسکیل ایبلٹی کا امتزاج ایک بہت ہی طاقتور مجموعہ ہے۔ اعلی کارکردگی کی ایپلی کیشنز عام طور پر وسائل کو کم استعمال کرتے ہیں اور اس طرح لاگت کو کم کرتے ہوئے سرور پر زیادہ ہم آہنگی صارفین کو موثر طریقے سے پیش کرتے ہیں۔
CPU اور I/O کام
آخر میں، کمپیوٹنگ میں ہمیشہ دو قسم کے کام ہوتے ہیں: I/O اور CPU کے لیے۔ انٹرنیٹ پر درخواستیں وصول کرنا (نیٹ ورک I/O)، فائلیں پیش کرنا (نیٹ ورک اور ڈسک I/O)، ڈیٹا بیس (نیٹ ورک اور ڈسک I/O) کے ساتھ بات چیت کرنا سبھی I/O سرگرمیاں ہیں۔ کچھ ڈیٹا بیس کے سوالات قدرے سی پی یو کی گہرائی میں ہوسکتے ہیں (چھانٹنا، ایک ملین نتائج کا اوسط، وغیرہ)۔ زیادہ تر ویب ایپلیکیشنز زیادہ سے زیادہ ممکنہ I/O تک محدود ہیں، اور پروسیسر شاذ و نادر ہی پوری صلاحیت کے ساتھ استعمال ہوتا ہے۔ جب آپ دیکھتے ہیں کہ کچھ I/O ٹاسک بہت زیادہ CPU استعمال کر رہا ہے، تو یہ غالباً ناقص ایپلیکیشن فن تعمیر کی علامت ہے۔ اس کا مطلب یہ ہو سکتا ہے کہ سی پی یو کے وسائل پروسیس مینجمنٹ اور سیاق و سباق کی تبدیلی پر ضائع ہو رہے ہیں - اور یہ مکمل طور پر مفید نہیں ہے۔ اگر آپ امیج پروسیسنگ، آڈیو فائل کنورژن، یا مشین لرننگ جیسا کچھ کر رہے ہیں، تو ایپلیکیشن کو طاقتور CPU وسائل کی ضرورت ہے۔ لیکن زیادہ تر ایپلی کیشنز کے لیے ایسا نہیں ہے۔
سرور آرکیٹیکچرز کے بارے میں مزید جانیں۔
ماخذ: www.habr.com