যথেষ্ট "নিম্ন" বিশদ রয়েছে।
প্রথমে বিবেচনা করুন যে কার্নেলের কাছে প্রক্রিয়াগুলির একটি তালিকা রয়েছে এবং যে কোনও সময় এই প্রসেসগুলির মধ্যে কয়েকটি চলমান রয়েছে, এবং কিছু নেই। কার্নেল প্রতিটি চলমান প্রক্রিয়াটিকে সিপিইউ সময়ের কয়েকটি স্লাইস করার অনুমতি দেয়, তারপরে এটি বাধা দেয় এবং পরবর্তীটিতে চলে যায়। যদি কোনও চলমান প্রক্রিয়া না থাকে তবে কার্নেলটি সম্ভবত সিপিইউতে এইচএলটি -র মতো একটি নির্দেশনা দেবে যা একটি হার্ডওয়্যার বিঘ্ন না হওয়া পর্যন্ত সিপিইউ স্থগিত করে।
কোথাও সার্ভারে এমন একটি সিস্টেম কল রয়েছে যা "আমাকে কিছু করার জন্য দিন" বলে। এটি করা যেতে পারে এমন দুটি বিস্তৃত বিভাগ। অ্যাপাচি এর ক্ষেত্রে এটি accept
সকেটে কল করে যা আগে অ্যাপাচি খুলেছিল, সম্ভবত পোর্ট ৮০ এ শুনছে ker কার্নেল সংযোগের চেষ্টাগুলির একটি সারি বজায় রাখে এবং প্রতিবার টিসিপি এসওয়াইএন পাওয়ার সাথে সাথে এই সারিটি যুক্ত করে । কার্নেল টিসিপি এসওয়াইএন প্রাপ্ত হয়েছিল কীভাবে তা ডিভাইস ড্রাইভারের উপর নির্ভর করে; অনেক এনআইসি-র ক্ষেত্রে নেটওয়ার্কের ডেটা পাওয়ার পরে সম্ভবত একটি হার্ডওয়্যার বিঘ্ন ঘটেছে।
accept
কার্নেলটিকে পরবর্তী সংযোগ দীক্ষাটি আমার কাছে ফিরে আসতে বলুন। যদি সারিটি খালি না ছিল, তবে accept
কেবল অবিলম্বে ফিরে আসবে । যদি সারিটি খালি থাকে তবে প্রক্রিয়াটি (অ্যাপাচি) চলমান প্রক্রিয়াগুলির তালিকা থেকে সরানো হবে। পরে কোনও সংযোগ শুরু করা হলে, প্রক্রিয়াটি আবার শুরু হয়। এটিকে "ব্লকিং" বলা হয়, কারণ এটি কল করার প্রক্রিয়াটিকে accept()
এমন কোনও ফাংশনের মতো দেখায় যা ফল না পাওয়া পর্যন্ত ফিরে আসে না, যা এখন থেকে কিছুটা সময় হতে পারে। সেই সময় প্রক্রিয়াটি আর কিছুই করতে পারে না।
একবার accept
ফিরে আসার পরে , অ্যাপাচি জানে যে কেউ সংযোগ দেওয়ার চেষ্টা করছেন। এরপরে অ্যাপাচি প্রক্রিয়াটিকে দুটি অভিন্ন প্রক্রিয়াতে ভাগ করার জন্য কাঁটাচামচ কল করে। এইগুলির মধ্যে একটি HTTP অনুরোধটি প্রক্রিয়া করতে চলেছে, অন্য accept
সংযোগটি পরবর্তী সংযোগ পেতে আবার কল করে calls সুতরাং, সর্বদা একটি মাস্টার প্রক্রিয়া থাকে যা কল accept
এবং উপ-প্রক্রিয়াগুলি স্পন ছাড়া কিছুই করে না এবং তারপরে প্রতিটি অনুরোধের জন্য একটি উপ-প্রক্রিয়া রয়েছে।
এটি সরলকরণ: প্রক্রিয়াগুলির পরিবর্তে থ্রেডগুলির সাহায্যে এটি করা সম্ভব এবং অনুরোধ fork
পেলে একটি শ্রমিক প্রক্রিয়া প্রস্তুত থাকে, সুতরাং প্রারম্ভিক ওভারহেড হ্রাস করে। অ্যাপাচি কীভাবে এটি কনফিগার করা হয়েছে তার উপর নির্ভর করে এই যে কোনও একটি কাজ করতে পারে।
এটা কিভাবে করতে হবে প্রথম বৃহত্ শ্রেণীর, এবং এটি বলা হচ্ছে আই ব্লক কারণ সিস্টেম মত কল accept
এবং read
এবং write
যা সকেট কাজ প্রক্রিয়া স্থগিত থাকবে যতক্ষন না তারা ফিরে যাওয়ার কিছু আছে।
এটি করার অন্যান্য বিস্তৃত উপায়কে অ-ব্লকিং বা ইভেন্ট ভিত্তিক বা অ্যাসিঙ্ক্রোনাস আইও বলা হয় । এটি সিস্টেম কল select
বা এর মতো প্রয়োগ করা হয় epoll
। এগুলি প্রত্যেকে একই কাজ করে: আপনি তাদের সকেটের একটি তালিকা দিন (বা সাধারণভাবে, ফাইল বর্ণনাকারী) এবং আপনি তাদের সাথে কী করতে চান এবং কার্নেল সেগুলির মধ্যে একটি কাজ করার জন্য প্রস্তুত না হওয়া পর্যন্ত অবরুদ্ধ করে।
এই মডেলটির সাহায্যে, আপনি কার্নেলকে (সহ epoll
) বলতে পারেন, "আমার যখন খোলা এই অন্যান্য 9471 সংযোগের কোনওটিতে পোর্ট ৮০ বা নতুন ডেটাতে নতুন সংযোগ রয়েছে তখন আমাকে বলুন" " epoll
এইগুলির মধ্যে একটির প্রস্তুত না হওয়া অবধি অবরুদ্ধ থাকে, তবে আপনি এটি করুন। তারপরে আপনি পুনরাবৃত্তি করুন। সিস্টেম কল মত accept
এবং read
এবং write
কখনও ব্লক, আংশিকভাবে কারণ যখনই আপনি তাদের কল, epoll
শুধু আপনার বলছে যে তারা প্রস্তুত হয় তাই ব্লক কোনো কারণ হতে চাই, এবং এছাড়াও কারণ যখন আপনি সকেট বা ফাইল আপনার নির্দিষ্ট করা খুলুন আপনি তাদের চাই যে নন-ব্লকিং মোডে, সুতরাং সেই কলগুলি EWOULDBLOCK
ব্লক করার পরিবর্তে ব্যর্থ হবে ।
এই মডেলটির সুবিধাটি হ'ল আপনার কেবল একটি প্রক্রিয়া দরকার। এর অর্থ প্রতিটি অনুরোধের জন্য আপনাকে স্ট্যাক এবং কার্নেল কাঠামো বরাদ্দ করতে হবে না। Nginx এবং HAProxy এই মডেলটি ব্যবহার করে এবং এটি একই ধরণের হার্ডওয়্যারে অ্যাপাচি এর চেয়ে আরও অনেক সংযোগের সাথে ডিল করতে পারে তার একটি বড় কারণ।