ওয়েব অ্যাপ্লিকেশনগুলি এখন সর্বত্র ব্যবহৃত হয়, এবং সমস্ত পরিবহন প্রোটোকলের মধ্যে, এইচটিটিপি সিংহভাগ দখল করে। ওয়েব অ্যাপ্লিকেশন ডেভেলপমেন্টের সূক্ষ্মতাগুলি অধ্যয়ন করার সময়, বেশিরভাগ লোকেরা অপারেটিং সিস্টেমের দিকে খুব কম মনোযোগ দেয় যেখানে এই অ্যাপ্লিকেশনগুলি আসলে চালিত হয়। উন্নয়ন (দেব) এবং অপারেশন (অপস) এর পৃথকীকরণ পরিস্থিতিকে আরও খারাপ করেছে। কিন্তু DevOps সংস্কৃতির উত্থানের সাথে, বিকাশকারীরা ক্লাউডে তাদের অ্যাপ্লিকেশনগুলি চালানোর জন্য দায়ী হয়ে উঠছে, তাই অপারেটিং সিস্টেমের ব্যাকএন্ডের সাথে পুরোপুরি পরিচিত হওয়া তাদের পক্ষে খুব দরকারী। এটি বিশেষভাবে উপযোগী যদি আপনি হাজার হাজার বা হাজার হাজার যুগপত সংযোগের জন্য একটি সিস্টেম স্থাপন করার চেষ্টা করেন।

ওয়েব পরিষেবাগুলির সীমাবদ্ধতাগুলি অন্যান্য অ্যাপ্লিকেশনগুলির মতোই। এটি লোড ব্যালেন্সার বা ডাটাবেস সার্ভার হোক না কেন, এই সমস্ত অ্যাপ্লিকেশনগুলির একটি উচ্চ-পারফরম্যান্স পরিবেশে একই রকম সমস্যা রয়েছে। এই মৌলিক সীমাবদ্ধতাগুলি বোঝা এবং সাধারণভাবে কীভাবে সেগুলি অতিক্রম করা যায় তা আপনাকে আপনার ওয়েব অ্যাপ্লিকেশনগুলির কার্যকারিতা এবং মাপযোগ্যতা মূল্যায়ন করতে সহায়তা করবে৷

আমি এই সিরিজের নিবন্ধগুলি লিখছি তরুণ ডেভেলপারদের প্রশ্নের উত্তরে যারা সু-জ্ঞাত সিস্টেম আর্কিটেক্ট হতে চান। লিনাক্স অ্যাপ্লিকেশন অপ্টিমাইজেশান কৌশলগুলি অপারেটিং সিস্টেম স্তরে কীভাবে কাজ করে তার মূল বিষয়গুলিতে ডুব না দিয়ে স্পষ্টভাবে বোঝা অসম্ভব। যদিও অনেক ধরনের অ্যাপ্লিকেশন রয়েছে, এই সিরিজে আমি ব্রাউজার বা টেক্সট এডিটরের মতো ডেস্কটপ অ্যাপ্লিকেশনের পরিবর্তে ওয়েব-ভিত্তিক অ্যাপ্লিকেশনগুলি অন্বেষণ করতে চাই। এই উপাদানটি ডেভেলপার এবং স্থপতিদের জন্য যারা লিনাক্স বা ইউনিক্স প্রোগ্রামগুলি কীভাবে কাজ করে এবং উচ্চ কার্যক্ষমতার জন্য কীভাবে তাদের গঠন করতে চান তা বুঝতে চান।

লিনাক্স হল সার্ভার রুমে অপারেটিং সিস্টেম, এবং প্রায়শই আপনার অ্যাপ্লিকেশনগুলি এই OS এ চলে। যদিও আমি বলি "লিনাক্স", বেশিরভাগ সময় আপনি নিরাপদে ধরে নিতে পারেন যে আমি সাধারণভাবে ইউনিক্স-এর মতো অপারেটিং সিস্টেম বলতে চাই। যাইহোক, আমি অন্যান্য সিস্টেমে সহকারী কোড পরীক্ষা করিনি। সুতরাং, আপনি যদি FreeBSD বা OpenBSD-এ আগ্রহী হন, তাহলে আপনার ফলাফল পরিবর্তিত হতে পারে। যখন আমি লিনাক্স-নির্দিষ্ট কিছু চেষ্টা করি, আমি এটি নির্দেশ করি।

আপনি স্ক্র্যাচ থেকে একটি অ্যাপ তৈরি করতে এই জ্ঞান ব্যবহার করতে পারেন এবং এটি পুরোপুরি অপ্টিমাইজ করা হবে, এটি না করাই ভাল। আপনি যদি আপনার প্রতিষ্ঠানের ব্যবসায়িক অ্যাপ্লিকেশনের জন্য C বা C++ এ একটি নতুন ওয়েব সার্ভার লেখেন, তাহলে এটিই হতে পারে আপনার কাজের শেষ দিন। যাইহোক, এই অ্যাপ্লিকেশনগুলির কাঠামো জানা বিদ্যমান প্রোগ্রামগুলি বেছে নিতে সহায়তা করবে। আপনি প্রক্রিয়া-ভিত্তিক সিস্টেমগুলিকে থ্রেড-ভিত্তিক সিস্টেমের পাশাপাশি ইভেন্ট-ভিত্তিক সিস্টেমগুলির সাথে তুলনা করতে সক্ষম হবেন। আপনি বুঝতে পারবেন এবং উপলব্ধি করবেন কেন Nginx Apache httpd এর চেয়ে ভাল পারফরম্যান্স করে, কেন একটি টর্নেডো ভিত্তিক পাইথন অ্যাপ্লিকেশন একটি জ্যাঙ্গো ভিত্তিক পাইথন অ্যাপ্লিকেশনের তুলনায় বেশি ব্যবহারকারীদের পরিবেশন করতে পারে।

ZeroHTTPd: শেখার টুল

ZeroHTTPd একটি ওয়েব সার্ভার যা আমি শিক্ষণ সরঞ্জাম হিসাবে সি-তে স্ক্র্যাচ থেকে লিখেছিলাম। রেডিস অ্যাক্সেস সহ এর কোনও বাহ্যিক নির্ভরতা নেই। আমরা আমাদের নিজস্ব রেডিস পদ্ধতি চালাই। আরো বিস্তারিত জানার জন্য নিচে দেখুন।

যদিও আমরা তত্ত্ব নিয়ে আলোচনা করতে পারি, কোড লেখা, এটি চালানো এবং একে অপরের সাথে সমস্ত সার্ভার আর্কিটেকচার তুলনা করার চেয়ে ভাল আর কিছুই নেই। এটি সবচেয়ে সুস্পষ্ট পদ্ধতি। অতএব, আমরা প্রতিটি মডেল ব্যবহার করে একটি সাধারণ ZeroHTTPd ওয়েব সার্ভার লিখব: প্রক্রিয়া-ভিত্তিক, থ্রেড-ভিত্তিক এবং ইভেন্ট-ভিত্তিক। আসুন এই সার্ভারগুলির প্রতিটি পরীক্ষা করে দেখুন এবং দেখুন কিভাবে তারা একে অপরের তুলনায় কার্য সম্পাদন করে। ZeroHTTPd একটি একক C ফাইলে প্রয়োগ করা হয় উথাশ, একটি দুর্দান্ত হ্যাশ টেবিল বাস্তবায়ন যা একটি একক হেডার ফাইলে আসে। অন্যান্য ক্ষেত্রে, কোন নির্ভরতা নেই, যাতে প্রকল্পটি জটিল না হয়।

আপনাকে বুঝতে সাহায্য করার জন্য কোডটিতে প্রচুর মন্তব্য রয়েছে। কোডের কয়েকটি লাইনে একটি সাধারণ ওয়েব সার্ভার হওয়ার কারণে, ZeroHTTPd ওয়েব বিকাশের জন্য একটি ন্যূনতম কাঠামো। এটির কার্যকারিতা সীমিত, তবে এটি স্ট্যাটিক ফাইল এবং খুব সাধারণ "ডাইনামিক" পৃষ্ঠাগুলি পরিবেশন করতে সক্ষম। আমাকে বলতে হবে যে ZeroHTTPd কীভাবে উচ্চ-পারফরম্যান্স লিনাক্স অ্যাপ্লিকেশন তৈরি করতে হয় তা শেখার জন্য ভাল। সর্বোপরি, বেশিরভাগ ওয়েব পরিষেবাগুলি অনুরোধের জন্য অপেক্ষা করে, সেগুলি পরীক্ষা করে এবং সেগুলি প্রক্রিয়া করে৷ এটা ঠিক কি ZeroHTTPd করবে। এটি শেখার একটি হাতিয়ার, উৎপাদন নয়। এটি ত্রুটি পরিচালনার ক্ষেত্রে দুর্দান্ত নয় এবং সর্বোত্তম সুরক্ষা অনুশীলনের গর্ব করার সম্ভাবনা নেই (ওহ হ্যাঁ, আমি ব্যবহার করেছি strcpy) বা সি ভাষার চতুর কৌশলগুলি কিন্তু আমি আশা করি এটি তার কাজটি ভাল করে।

ZeroHTTPd হোম পেজ। এটি ছবি সহ বিভিন্ন ধরনের ফাইল আউটপুট করতে পারে

অতিথি বইয়ের আবেদন

আধুনিক ওয়েব অ্যাপ্লিকেশনগুলি সাধারণত স্ট্যাটিক ফাইলগুলিতে সীমাবদ্ধ থাকে না। তাদের বিভিন্ন ডাটাবেস, ক্যাশে ইত্যাদির সাথে জটিল মিথস্ক্রিয়া রয়েছে। তাই আমরা "গেস্ট বুক" নামে একটি সাধারণ ওয়েব অ্যাপ্লিকেশন তৈরি করব যেখানে দর্শকরা তাদের নামের নিচে এন্ট্রি ছেড়ে যাবে। গেস্ট বুক স্টোর এন্ট্রি আগে বাকি. পৃষ্ঠার নীচে একটি ভিজিটর কাউন্টারও রয়েছে।

ওয়েব অ্যাপ্লিকেশন "গেস্ট বুক" ZeroHTTPd

ভিজিটর কাউন্টার এবং গেস্ট বুক এন্ট্রি রেডিসে সংরক্ষিত আছে। রেডিসের সাথে যোগাযোগের জন্য, নিজস্ব পদ্ধতি প্রয়োগ করা হয়; তারা বাহ্যিক গ্রন্থাগারের উপর নির্ভর করে না। যখন সর্বজনীনভাবে উপলব্ধ এবং ভাল-পরীক্ষিত সমাধান থাকে তখন আমি হোমব্রু কোড চালু করার বড় ভক্ত নই। কিন্তু ZeroHTTPd এর উদ্দেশ্য হল লিনাক্সের কর্মক্ষমতা অধ্যয়ন করা এবং বাহ্যিক পরিষেবাগুলিতে অ্যাক্সেস করা, যখন HTTP অনুরোধগুলি পরিবেশন করা একটি গুরুতর কর্মক্ষমতা প্রভাব ফেলে। আমাদের প্রতিটি সার্ভার আর্কিটেকচারে Redis-এর সাথে যোগাযোগ সম্পূর্ণরূপে নিয়ন্ত্রণ করতে হবে। কিছু আর্কিটেকচারে আমরা ব্লকিং কল ব্যবহার করি, অন্যগুলোতে আমরা ইভেন্ট-ভিত্তিক পদ্ধতি ব্যবহার করি। একটি বহিরাগত Redis ক্লায়েন্ট লাইব্রেরি ব্যবহার করে এই নিয়ন্ত্রণ প্রদান করবে না। উপরন্তু, আমাদের ছোট রেডিস ক্লায়েন্ট শুধুমাত্র কয়েকটি ফাংশন সম্পাদন করে (একটি কী পাওয়া, সেট করা এবং বৃদ্ধি করা; একটি অ্যারে পাওয়া এবং যুক্ত করা)। উপরন্তু, 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: এই সার্ভারটি Redis ডেমন চালায়, যেখানে গেস্টবুক এন্ট্রি এবং ভিজিটর কাউন্টার সংরক্ষণ করা হয়।

সমস্ত সার্ভার একই প্রসেসর কোরে চলে। ধারণা হল প্রতিটি আর্কিটেকচারের সর্বোচ্চ কর্মক্ষমতা মূল্যায়ন করা। যেহেতু সমস্ত সার্ভার প্রোগ্রাম একই হার্ডওয়্যারে পরীক্ষা করা হয়, এটি তুলনা করার জন্য একটি বেসলাইন। আমার পরীক্ষা সেটআপ ডিজিটাল মহাসাগর থেকে ভাড়া ভার্চুয়াল সার্ভার নিয়ে গঠিত।

আমরা কি পরিমাপ করছি?

আপনি বিভিন্ন সূচক পরিমাপ করতে পারেন। আমরা সমান্তরালতার বিভিন্ন স্তরে অনুরোধ সহ সার্ভারগুলিকে লোড করার মাধ্যমে একটি প্রদত্ত কনফিগারেশনে প্রতিটি আর্কিটেকচারের কার্যকারিতা মূল্যায়ন করি: লোড 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
-
-
বড় বিস্তার
-
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_ফোরকিং │ ├── main.c ├── main.c ├── 03_preforking 04_ম পঠন │ ├── main.c ├── 05_প্রিথ্রেডিং │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ │ └── main.c ├├─le─ main.c ├ করুন ├── index.html │ └── টাক্স png └── টেমপ্লেট └── গেস্টবুক └── index.html

সমস্ত আর্কিটেকচারের জন্য সাতটি ডিরেক্টরি ছাড়াও, শীর্ষ-স্তরের ডিরেক্টরিতে আরও দুটি রয়েছে: সর্বজনীন এবং টেমপ্লেট। প্রথমটিতে index.html ফাইল এবং প্রথম স্ক্রিনশট থেকে ছবি রয়েছে৷ আপনি সেখানে অন্যান্য ফাইল এবং ফোল্ডার রাখতে পারেন এবং ZeroHTTPd কোন সমস্যা ছাড়াই সেই স্ট্যাটিক ফাইলগুলিকে পরিবেশন করা উচিত। যদি ব্রাউজারে পাথটি পাবলিক ফোল্ডারের পাথের সাথে মেলে, তাহলে ZeroHTTPd এই ডিরেক্টরিতে index.html ফাইলটি সন্ধান করে। অতিথি বইয়ের বিষয়বস্তু গতিশীলভাবে তৈরি হয়। এটির শুধুমাত্র একটি হোম পেজ রয়েছে এবং এর বিষয়বস্তু 'টেমপ্লেট/গেস্টবুক/index.html' ফাইলের উপর ভিত্তি করে। ZeroHTTPd সহজেই এক্সটেনশনের জন্য গতিশীল পৃষ্ঠাগুলি যোগ করে। ধারণাটি হল যে ব্যবহারকারীরা এই ডিরেক্টরিতে টেমপ্লেট যোগ করতে পারে এবং প্রয়োজন অনুসারে ZeroHTTPd প্রসারিত করতে পারে।

সমস্ত সাতটি সার্ভার তৈরি করতে, চালান make all শীর্ষ-স্তরের ডিরেক্টরি থেকে - এবং সমস্ত বিল্ড এই ডিরেক্টরিতে প্রদর্শিত হবে। এক্সিকিউটেবল ফাইলগুলি যে ডিরেক্টরি থেকে চালু করা হয়েছে সেখানে সর্বজনীন এবং টেমপ্লেট ডিরেক্টরিগুলির সন্ধান করে।

লিনাক্স এপিআই

এই নিবন্ধ সিরিজের তথ্য বুঝতে আপনাকে Linux API-তে পারদর্শী হতে হবে না। যাইহোক, আমি এই বিষয়ে আরো পড়ার পরামর্শ দিচ্ছি ইন্টারনেটে অনেক রেফারেন্স রিসোর্স আছে। যদিও আমরা লিনাক্স এপিআই-এর বিভিন্ন বিভাগে স্পর্শ করব, আমাদের ফোকাস হবে প্রাথমিকভাবে প্রসেস, থ্রেড, ইভেন্ট এবং নেটওয়ার্ক স্ট্যাকের উপর। লিনাক্স এপিআই সম্পর্কে বই এবং নিবন্ধগুলি ছাড়াও, আমি সিস্টেম কল এবং ব্যবহৃত লাইব্রেরি ফাংশনগুলির জন্য মানা পড়ার পরামর্শ দিই।

কর্মক্ষমতা এবং মাপযোগ্যতা

কর্মক্ষমতা এবং মাপযোগ্যতা সম্পর্কে একটি নোট। তাত্ত্বিকভাবে, তাদের মধ্যে কোন সংযোগ নেই। আপনার কাছে একটি ওয়েব পরিষেবা থাকতে পারে যা খুব ভাল কাজ করে, কয়েক মিলিসেকেন্ডের প্রতিক্রিয়ার সময়, কিন্তু এটি মোটেও স্কেল করে না। একইভাবে, একটি খারাপ পারফরম্যান্সকারী ওয়েব অ্যাপ্লিকেশন থাকতে পারে যা প্রতিক্রিয়া জানাতে কয়েক সেকেন্ড সময় নেয়, তবে এটি হাজার হাজার সমসাময়িক ব্যবহারকারীদের পরিচালনার জন্য দশ দ্বারা স্কেল করে। যাইহোক, উচ্চ কর্মক্ষমতা এবং মাপযোগ্যতার সংমিশ্রণ একটি খুব শক্তিশালী সমন্বয়। উচ্চ-পারফরম্যান্স অ্যাপ্লিকেশানগুলি সাধারণত সম্পদগুলি অল্প ব্যবহার করে এবং এইভাবে দক্ষতার সাথে সার্ভারে আরও সমসাময়িক ব্যবহারকারীদের পরিবেশন করে, খরচ কমিয়ে দেয়।

CPU এবং I/O কাজ

পরিশেষে, কম্পিউটিংয়ে সবসময় দুটি সম্ভাব্য ধরনের কাজ থাকে: I/O এবং CPU-এর জন্য। ইন্টারনেটের মাধ্যমে অনুরোধ গ্রহণ করা (নেটওয়ার্ক I/O), ফাইল পরিবেশন করা (নেটওয়ার্ক এবং ডিস্ক I/O), ডাটাবেসের সাথে যোগাযোগ করা (নেটওয়ার্ক এবং ডিস্ক I/O) হল সমস্ত I/O কার্যকলাপ। কিছু ডাটাবেস ক্যোয়ারী কিছুটা CPU নিবিড় হতে পারে (বাছাই করা, এক মিলিয়ন ফলাফলের গড়, ইত্যাদি)। বেশিরভাগ ওয়েব অ্যাপ্লিকেশন সর্বাধিক সম্ভাব্য I/O দ্বারা সীমাবদ্ধ, এবং প্রসেসর খুব কমই পূর্ণ ক্ষমতায় ব্যবহৃত হয়। আপনি যখন দেখেন যে কিছু I/O টাস্ক প্রচুর CPU ব্যবহার করছে, এটি সম্ভবত দুর্বল অ্যাপ্লিকেশন আর্কিটেকচারের লক্ষণ। এর অর্থ হতে পারে যে প্রক্রিয়া পরিচালনা এবং প্রসঙ্গ স্যুইচিংয়ের জন্য সিপিইউ সংস্থানগুলি নষ্ট হয় - এবং এটি সম্পূর্ণরূপে কার্যকর নয়। আপনি যদি ইমেজ প্রসেসিং, অডিও ফাইল কনভার্সন বা মেশিন লার্নিং এর মত কিছু করছেন, তাহলে অ্যাপ্লিকেশনটির জন্য শক্তিশালী CPU রিসোর্স প্রয়োজন। কিন্তু বেশিরভাগ অ্যাপ্লিকেশনের ক্ষেত্রে এটি হয় না।

সার্ভার আর্কিটেকচার সম্পর্কে আরও জানুন

উত্স: www.habr.com

লিনাক্স নেটওয়ার্ক অ্যাপ্লিকেশন কর্মক্ষমতা. ভূমিকা