వెబ్ అప్లికేషన్లు ఇప్పుడు ప్రతిచోటా ఉపయోగించబడుతున్నాయి మరియు అన్ని రవాణా ప్రోటోకాల్‌లలో, HTTP సింహభాగాన్ని ఆక్రమించింది. వెబ్ అప్లికేషన్ డెవలప్‌మెంట్ యొక్క సూక్ష్మ నైపుణ్యాలను అధ్యయనం చేస్తున్నప్పుడు, చాలా మంది వ్యక్తులు ఈ అప్లికేషన్లు వాస్తవానికి అమలు చేసే ఆపరేటింగ్ సిస్టమ్‌పై చాలా తక్కువ శ్రద్ధ చూపుతారు. అభివృద్ధి (Dev) మరియు కార్యకలాపాలు (Ops) వేరు చేయడం వల్ల పరిస్థితి మరింత దిగజారింది. కానీ DevOps సంస్కృతి పెరగడంతో, డెవలపర్‌లు తమ అప్లికేషన్‌లను క్లౌడ్‌లో రన్ చేయడానికి బాధ్యత వహిస్తున్నారు, కాబట్టి ఆపరేటింగ్ సిస్టమ్ యొక్క బ్యాకెండ్ గురించి పూర్తిగా తెలుసుకోవడం వారికి చాలా ఉపయోగకరంగా ఉంటుంది. మీరు వేల లేదా పదివేల ఏకకాల కనెక్షన్‌ల కోసం సిస్టమ్‌ని అమలు చేయడానికి ప్రయత్నిస్తున్నట్లయితే ఇది ప్రత్యేకంగా ఉపయోగపడుతుంది.
వెబ్ సేవలలోని పరిమితులు ఇతర అప్లికేషన్‌లలో ఉన్న వాటితో సమానంగా ఉంటాయి. ఇది లోడ్ బ్యాలెన్సర్‌లు లేదా డేటాబేస్ సర్వర్లు అయినా, ఈ అప్లికేషన్‌లన్నింటికీ అధిక-పనితీరు వాతావరణంలో ఒకే విధమైన సమస్యలు ఉంటాయి. ఈ ప్రాథమిక పరిమితులను అర్థం చేసుకోవడం మరియు సాధారణంగా వాటిని ఎలా అధిగమించాలి అనేది మీ వెబ్ అప్లికేషన్‌ల పనితీరు మరియు స్కేలబిలిటీని అంచనా వేయడంలో మీకు సహాయం చేస్తుంది.
బాగా సమాచారం ఉన్న సిస్టమ్ ఆర్కిటెక్ట్‌లుగా మారాలనుకునే యువ డెవలపర్‌ల ప్రశ్నలకు ప్రతిస్పందనగా నేను ఈ కథనాల శ్రేణిని వ్రాస్తున్నాను. Linux అప్లికేషన్ ఆప్టిమైజేషన్ టెక్నిక్‌లు ఆపరేటింగ్ సిస్టమ్ స్థాయిలో ఎలా పని చేస్తాయనే బేసిక్స్‌లో డైవ్ చేయకుండా స్పష్టంగా అర్థం చేసుకోవడం అసాధ్యం. అనేక రకాల అప్లికేషన్లు ఉన్నప్పటికీ, ఈ సిరీస్‌లో నేను బ్రౌజర్ లేదా టెక్స్ట్ ఎడిటర్ వంటి డెస్క్‌టాప్ అప్లికేషన్‌ల కంటే వెబ్ ఆధారిత అప్లికేషన్‌లను అన్వేషించాలనుకుంటున్నాను. ఈ మెటీరియల్ డెవలపర్‌లు మరియు ఆర్కిటెక్ట్‌ల కోసం ఉద్దేశించబడింది, వారు Linux లేదా Unix ప్రోగ్రామ్‌లు ఎలా పని చేస్తారో మరియు వాటిని అధిక పనితీరు కోసం ఎలా రూపొందించాలో అర్థం చేసుకోవాలి.
Linux ఉంది సర్వర్ గది ఆపరేటింగ్ సిస్టమ్, మరియు చాలా తరచుగా మీ అప్లికేషన్లు ఈ OSలో రన్ అవుతాయి. నేను "Linux" అని చెప్పినప్పటికీ, నేను సాధారణంగా అన్ని Unix-వంటి ఆపరేటింగ్ సిస్టమ్‌లను ఉద్దేశించినట్లు మీరు చాలా వరకు సురక్షితంగా భావించవచ్చు. అయితే, నేను ఇతర సిస్టమ్‌లలో దానితో కూడిన కోడ్‌ని పరీక్షించలేదు. కాబట్టి, మీకు FreeBSD లేదా OpenBSD పట్ల ఆసక్తి ఉంటే, మీ ఫలితాలు మారవచ్చు. నేను Linux-నిర్దిష్ట ఏదైనా ప్రయత్నించినప్పుడు, నేను దానిని ఎత్తి చూపుతాను.
మీరు మొదటి నుండి ఒక యాప్‌ను రూపొందించడానికి ఈ పరిజ్ఞానాన్ని ఉపయోగించుకోవచ్చు మరియు ఇది ఖచ్చితంగా ఆప్టిమైజ్ చేయబడుతుంది, అలా చేయకపోవడమే ఉత్తమం. మీరు మీ సంస్థ యొక్క వ్యాపార అప్లికేషన్ కోసం C లేదా C++లో కొత్త వెబ్ సర్వర్‌ని వ్రాస్తే, ఉద్యోగంలో ఇదే మీ చివరి రోజు కావచ్చు. అయితే, ఈ అప్లికేషన్‌ల నిర్మాణాన్ని తెలుసుకోవడం ఇప్పటికే ఉన్న ప్రోగ్రామ్‌లను ఎంచుకోవడంలో సహాయపడుతుంది. మీరు ప్రక్రియ-ఆధారిత సిస్టమ్‌లను థ్రెడ్-ఆధారిత సిస్టమ్‌లతో పాటు ఈవెంట్-ఆధారిత సిస్టమ్‌లతో పోల్చగలరు. అపాచీ httpd కంటే Nginx ఎందుకు మెరుగ్గా పనిచేస్తుందో, జంగో ఆధారిత పైథాన్ అప్లికేషన్‌తో పోలిస్తే సుడిగాలి ఆధారిత పైథాన్ అప్లికేషన్ ఎక్కువ మంది వినియోగదారులకు ఎందుకు సేవ చేయగలదో మీరు అర్థం చేసుకుంటారు మరియు అభినందిస్తారు.
ZeroHTTPd: అభ్యాస సాధనం
నేను మొదటి నుండి C లో బోధనా సాధనంగా వ్రాసిన వెబ్ సర్వర్. దీనికి Redis యాక్సెస్‌తో సహా బాహ్య డిపెండెన్సీలు లేవు. మేము మా స్వంత Redis విధానాలను అమలు చేస్తాము. మరిన్ని వివరాల కోసం క్రింద చూడండి.
మేము సిద్ధాంతాన్ని సుదీర్ఘంగా చర్చించగలిగినప్పటికీ, కోడ్ రాయడం, దాన్ని అమలు చేయడం మరియు అన్ని సర్వర్ ఆర్కిటెక్చర్‌లను ఒకదానితో ఒకటి పోల్చడం కంటే మెరుగైనది ఏమీ లేదు. ఇది అత్యంత స్పష్టమైన పద్ధతి. అందువల్ల, మేము ప్రతి మోడల్‌ని ఉపయోగించి ఒక సాధారణ ZeroHTTPd వెబ్ సర్వర్‌ను వ్రాస్తాము: ప్రాసెస్-ఆధారిత, థ్రెడ్-ఆధారిత మరియు ఈవెంట్-ఆధారిత. ఈ సర్వర్‌లలో ప్రతి ఒక్కటి తనిఖీ చేద్దాం మరియు అవి ఒకదానితో ఒకటి పోలిస్తే ఎలా పనిచేస్తుందో చూద్దాం. ZeroHTTPd ఒకే C ఫైల్‌లో అమలు చేయబడింది. ఈవెంట్-ఆధారిత సర్వర్‌లో చేర్చబడుతుంది , ఒకే హెడర్ ఫైల్‌లో వచ్చే గొప్ప హాష్ టేబుల్ అమలు. ఇతర సందర్భాల్లో, ప్రాజెక్ట్ను క్లిష్టతరం చేయకుండా ఉండటానికి డిపెండెన్సీలు లేవు.
మీరు అర్థం చేసుకోవడంలో సహాయపడేందుకు కోడ్‌లో చాలా వ్యాఖ్యలు ఉన్నాయి. కొన్ని పంక్తుల కోడ్‌లో సాధారణ వెబ్ సర్వర్‌గా ఉండటం వలన, ZeroHTTPd అనేది వెబ్ అభివృద్ధికి కనీస ఫ్రేమ్‌వర్క్ కూడా. ఇది పరిమిత కార్యాచరణను కలిగి ఉంది, కానీ స్టాటిక్ ఫైల్‌లను మరియు చాలా సులభమైన "డైనమిక్" పేజీలను అందించగలదు. అధిక-పనితీరు గల Linux అప్లికేషన్‌లను ఎలా సృష్టించాలో నేర్చుకోవడానికి ZeroHTTPd మంచిదని నేను చెప్పాలి. పెద్దగా, చాలా వెబ్ సేవలు అభ్యర్థనల కోసం వేచి ఉన్నాయి, వాటిని తనిఖీ చేసి వాటిని ప్రాసెస్ చేస్తాయి. ZeroHTTPd సరిగ్గా ఇదే చేస్తుంది. ఇది నేర్చుకోవడానికి ఒక సాధనం, ఉత్పత్తి కాదు. ఇది ఎర్రర్ హ్యాండ్లింగ్‌లో గొప్పది కాదు మరియు ఉత్తమ భద్రతా పద్ధతులను ప్రగల్భాలు చేసే అవకాశం లేదు (ఓహ్, నేను ఉపయోగించాను strcpy) లేదా C లాంగ్వేజ్ యొక్క తెలివైన ఉపాయాలు. కానీ అది తన పనిని బాగా చేస్తుందని నేను ఆశిస్తున్నాను.
ZeroHTTPd హోమ్ పేజీ. ఇది చిత్రాలతో సహా వివిధ రకాల ఫైల్‌లను అవుట్‌పుట్ చేయగలదు
గెస్ట్ బుక్ అప్లికేషన్
ఆధునిక వెబ్ అప్లికేషన్లు సాధారణంగా స్టాటిక్ ఫైల్‌లకు మాత్రమే పరిమితం కావు. వారు వివిధ డేటాబేస్‌లు, కాష్‌లు మొదలైన వాటితో సంక్లిష్టమైన పరస్పర చర్యలను కలిగి ఉంటారు. కాబట్టి మేము "అతిథి పుస్తకం" అనే సాధారణ వెబ్ అప్లికేషన్‌ను సృష్టిస్తాము, ఇక్కడ సందర్శకులు వారి పేర్లతో ఎంట్రీలను వదిలివేస్తాము. అతిథి పుస్తకం ముందుగా వదిలిపెట్టిన ఎంట్రీలను నిల్వ చేస్తుంది. పేజీ దిగువన సందర్శకుల కౌంటర్ కూడా ఉంది.
వెబ్ అప్లికేషన్ "గెస్ట్ బుక్" ZeroHTTPd
సందర్శకుల కౌంటర్ మరియు అతిథి పుస్తక ఎంట్రీలు Redisలో నిల్వ చేయబడతాయి. Redisతో కమ్యూనికేషన్ల కోసం, స్వంత విధానాలు అమలు చేయబడతాయి; అవి బాహ్య లైబ్రరీపై ఆధారపడవు. పబ్లిక్‌గా అందుబాటులో ఉన్న మరియు బాగా పరీక్షించిన పరిష్కారాలు ఉన్నప్పుడు హోమ్‌బ్రూ కోడ్‌ని విడుదల చేయడానికి నేను పెద్దగా ఇష్టపడను. కానీ ZeroHTTPd యొక్క ఉద్దేశ్యం Linux పనితీరును అధ్యయనం చేయడం మరియు బాహ్య సేవలకు ప్రాప్యత, HTTP అభ్యర్థనలను అందించడం వలన తీవ్రమైన పనితీరు ప్రభావం ఉంటుంది. మేము మా ప్రతి సర్వర్ ఆర్కిటెక్చర్‌లో Redisతో కమ్యూనికేషన్‌లను పూర్తిగా నియంత్రించాలి. కొన్ని ఆర్కిటెక్చర్‌లలో మేము బ్లాక్ చేసే కాల్‌లను ఉపయోగిస్తాము, మరికొన్నింటిలో మేము ఈవెంట్-ఆధారిత విధానాలను ఉపయోగిస్తాము. బాహ్య Redis క్లయింట్ లైబ్రరీని ఉపయోగించడం ఈ నియంత్రణను అందించదు. అదనంగా, మా చిన్న Redis క్లయింట్ కొన్ని విధులను మాత్రమే నిర్వహిస్తుంది (కీని పొందడం, సెట్ చేయడం మరియు పెంచడం; శ్రేణిని పొందడం మరియు జోడించడం). అదనంగా, Redis ప్రోటోకాల్ చాలా సొగసైనది మరియు సరళమైనది. మీరు ప్రత్యేకంగా బోధించాల్సిన అవసరం లేదు. ప్రోటోకాల్ దాదాపు వంద లైన్ల కోడ్‌లో అన్ని పనులను చేస్తుంది అనే వాస్తవం అది ఎంత బాగా ఆలోచించబడిందో చూపిస్తుంది.
క్లయింట్ (బ్రౌజర్) అభ్యర్థించినప్పుడు అప్లికేషన్ ఏమి చేస్తుందో క్రింది బొమ్మ చూపుతుంది /guestbookURL.
గెస్ట్ బుక్ అప్లికేషన్ ఎలా పనిచేస్తుంది
అతిథి పుస్తక పేజీని జారీ చేయవలసి వచ్చినప్పుడు, టెంప్లేట్‌ను మెమరీలోకి చదవడానికి ఫైల్ సిస్టమ్‌కు ఒక కాల్ మరియు Redisకి మూడు నెట్‌వర్క్ కాల్‌లు ఉంటాయి. టెంప్లేట్ ఫైల్ ఎగువ స్క్రీన్‌షాట్‌లోని పేజీకి సంబంధించిన చాలా HTML కంటెంట్‌ను కలిగి ఉంది. కంటెంట్ యొక్క డైనమిక్ భాగం కోసం ప్రత్యేక ప్లేస్‌హోల్డర్‌లు కూడా ఉన్నాయి: పోస్ట్‌లు మరియు సందర్శకుల కౌంటర్. మేము వాటిని Redis నుండి స్వీకరిస్తాము, వాటిని పేజీలోకి చొప్పించాము మరియు క్లయింట్‌కు పూర్తిగా రూపొందించిన కంటెంట్‌ను అందిస్తాము. రెడిస్‌కి మూడవ కాల్‌ని నివారించవచ్చు ఎందుకంటే రెడిస్ కొత్త కీ విలువను పెంచినప్పుడు తిరిగి ఇస్తుంది. అయినప్పటికీ, అసమకాలిక ఈవెంట్-ఆధారిత ఆర్కిటెక్చర్‌తో మా సర్వర్‌కు, చాలా నెట్‌వర్క్ కాల్‌లు అభ్యాస ప్రయోజనాల కోసం మంచి పరీక్ష. కాబట్టి మేము సందర్శకుల సంఖ్యకు సంబంధించిన Redis రిటర్న్ విలువను విస్మరించి, ప్రత్యేక కాల్‌తో ప్రశ్నిస్తాము.
సర్వర్ ఆర్కిటెక్చర్లు ZeroHTTPd
మేము ZeroHTTPd యొక్క ఏడు వెర్షన్‌లను ఒకే కార్యాచరణతో కానీ విభిన్న నిర్మాణాలతో రూపొందిస్తున్నాము:
- పునరావృతం
- ఫోర్క్ సర్వర్ (ఒక అభ్యర్థనకు ఒక చైల్డ్ ప్రాసెస్)
- ప్రీ-ఫోర్క్ సర్వర్ (ప్రాసెస్‌ల ప్రీ-ఫోర్కింగ్)
- అమలు థ్రెడ్‌లతో సర్వర్ (అభ్యర్థనకు ఒక థ్రెడ్)
- ప్రీ-థ్రెడ్ సృష్టితో సర్వర్
- ఆర్కిటెక్చర్ ఆధారంగా
poll() - ఆర్కిటెక్చర్ ఆధారంగా
epoll
HTTP అభ్యర్థనలతో సర్వర్‌ను లోడ్ చేయడం ద్వారా మేము ప్రతి ఆర్కిటెక్చర్ పనితీరును కొలుస్తాము. కానీ అత్యంత సమాంతర నిర్మాణాలను పోల్చినప్పుడు, ప్రశ్నల సంఖ్య పెరుగుతుంది. మేము మూడు సార్లు పరీక్షించి సగటును లెక్కిస్తాము.
పరీక్షా పద్దతి
ZeroHTTPd లోడ్ టెస్టింగ్ సెటప్
పరీక్షలను అమలు చేస్తున్నప్పుడు, అన్ని భాగాలు ఒకే మెషీన్‌లో పనిచేయకపోవడం ముఖ్యం. ఈ సందర్భంలో, భాగాలు CPU కోసం పోటీ పడుతున్నందున OS అదనపు షెడ్యూలింగ్ ఓవర్‌హెడ్‌ను కలిగి ఉంటుంది. ఎంచుకున్న ప్రతి సర్వర్ ఆర్కిటెక్చర్ యొక్క ఆపరేటింగ్ సిస్టమ్ ఓవర్‌హెడ్‌ను కొలవడం ఈ వ్యాయామం యొక్క అత్యంత ముఖ్యమైన లక్ష్యాలలో ఒకటి. మరిన్ని వేరియబుల్స్ జోడించడం ప్రక్రియకు హానికరంగా మారుతుంది. అందువల్ల, పై చిత్రంలో ఉన్న సెట్టింగ్ ఉత్తమంగా పనిచేస్తుంది.
ఈ సర్వర్‌లలో ప్రతి ఒక్కటి ఏమి చేస్తుంది?
- load.unixism.net: ఇక్కడే మనం రన్ చేస్తాము
ab, అపాచీ బెంచ్‌మార్క్ యుటిలిటీ. ఇది మా సర్వర్ ఆర్కిటెక్చర్‌లను పరీక్షించడానికి అవసరమైన లోడ్‌ను ఉత్పత్తి చేస్తుంది. - nginx.unixism.net: కొన్నిసార్లు మేము సర్వర్ ప్రోగ్రామ్ యొక్క ఒకటి కంటే ఎక్కువ ఉదాహరణలను అమలు చేయాలనుకుంటున్నాము. దీన్ని చేయడానికి, తగిన సెట్టింగ్‌లతో కూడిన Nginx సర్వర్ వచ్చే లోడ్ బ్యాలెన్సర్‌గా పనిచేస్తుంది ab మా సర్వర్ ప్రక్రియలకు.
- zerohttpd.unixism.net: ఇక్కడ మేము మా సర్వర్ ప్రోగ్రామ్‌లను ఏడు వేర్వేరు ఆర్కిటెక్చర్‌లలో ఒక్కొక్కటిగా అమలు చేస్తాము.
- redis.unixism.net: ఈ సర్వర్ Redis డెమోన్‌ను నడుపుతుంది, ఇక్కడ గెస్ట్‌బుక్ ఎంట్రీలు మరియు విజిటర్ కౌంటర్లు నిల్వ చేయబడతాయి.
అన్ని సర్వర్లు ఒకే ప్రాసెసర్ కోర్‌పై నడుస్తాయి. ప్రతి ఆర్కిటెక్చర్ యొక్క గరిష్ట పనితీరును అంచనా వేయాలనే ఆలోచన ఉంది. అన్ని సర్వర్ ప్రోగ్రామ్‌లు ఒకే హార్డ్‌వేర్‌పై పరీక్షించబడినందున, ఇది పోలిక కోసం బేస్‌లైన్. నా పరీక్ష సెటప్ డిజిటల్ ఓషన్ నుండి అద్దెకు తీసుకున్న వర్చువల్ సర్వర్‌లను కలిగి ఉంది.
మనం ఏమి కొలుస్తున్నాం?
మీరు వివిధ సూచికలను కొలవవచ్చు. సమాంతరత యొక్క వివిధ స్థాయిలలో అభ్యర్థనలతో సర్వర్‌లను లోడ్ చేయడం ద్వారా ఇచ్చిన కాన్ఫిగరేషన్‌లోని ప్రతి ఆర్కిటెక్చర్ పనితీరును మేము అంచనా వేస్తాము: లోడ్ 20 నుండి 15 ఏకకాల వినియోగదారులకు పెరుగుతుంది.
పరీక్ష ఫలితాలు
క్రింది చార్ట్ సమాంతరత యొక్క వివిధ స్థాయిలలో వివిధ నిర్మాణాలపై సర్వర్‌ల పనితీరును చూపుతుంది. y-axis అనేది సెకనుకు అభ్యర్థనల సంఖ్య, 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_ఫోర్కింగ్ 03_ థ్రెడింగ్ │ ├── main.c ├── 04_ప్రీథ్రెడింగ్ │ ├── main.c ├── 05_poll │ ├── main.c ├── 06_epoll │ │└── main.c│ ├── సూచిక .html │ └── tux png └── టెంప్లేట్‌లు └── అతిథి పుస్తకం └── index.html
అన్ని ఆర్కిటెక్చర్ల కోసం ఏడు డైరెక్టరీలతో పాటు, టాప్-లెవల్ డైరెక్టరీలో మరో రెండు ఉన్నాయి: పబ్లిక్ మరియు టెంప్లేట్‌లు. మొదటిది index.html ఫైల్ మరియు మొదటి స్క్రీన్‌షాట్ నుండి చిత్రాన్ని కలిగి ఉంటుంది. మీరు అక్కడ ఇతర ఫైల్‌లు మరియు ఫోల్డర్‌లను ఉంచవచ్చు మరియు ZeroHTTPd ఆ స్టాటిక్ ఫైల్‌లను ఎటువంటి సమస్యలు లేకుండా అందించాలి. బ్రౌజర్‌లోని మార్గం పబ్లిక్ ఫోల్డర్‌లోని పాత్‌తో సరిపోలితే, ZeroHTTPd ఈ డైరెక్టరీలోని index.html ఫైల్ కోసం చూస్తుంది. అతిథి పుస్తకం కోసం కంటెంట్ డైనమిక్‌గా రూపొందించబడింది. దీనికి హోమ్ పేజీ మాత్రమే ఉంది మరియు దాని కంటెంట్ 'templates/guestbook/index.html' ఫైల్‌పై ఆధారపడి ఉంటుంది. ZeroHTTPd పొడిగింపు కోసం డైనమిక్ పేజీలను సులభంగా జోడిస్తుంది. వినియోగదారులు ఈ డైరెక్టరీకి టెంప్లేట్‌లను జోడించవచ్చు మరియు ZeroHTTPdని అవసరమైన విధంగా పొడిగించవచ్చు.
మొత్తం ఏడు సర్వర్‌లను రూపొందించడానికి, అమలు చేయండి make all అగ్ర-స్థాయి డైరెక్టరీ నుండి - మరియు అన్ని బిల్డ్‌లు ఈ డైరెక్టరీలో కనిపిస్తాయి. ఎక్జిక్యూటబుల్ ఫైల్‌లు అవి ప్రారంభించబడిన డైరెక్టరీలోని పబ్లిక్ మరియు టెంప్లేట్ డైరెక్టరీల కోసం చూస్తాయి.
Linux API
ఈ ఆర్టికల్ సిరీస్‌లోని సమాచారాన్ని అర్థం చేసుకోవడానికి మీరు Linux API గురించి బాగా తెలుసుకోవాల్సిన అవసరం లేదు. అయితే, ఈ అంశంపై మరింత చదవమని నేను సిఫార్సు చేస్తున్నాను; ఇంటర్నెట్‌లో చాలా రిఫరెన్స్ వనరులు ఉన్నాయి. మేము Linux APIల యొక్క అనేక వర్గాలను తాకినప్పటికీ, మా దృష్టి ప్రధానంగా ప్రక్రియలు, థ్రెడ్‌లు, ఈవెంట్‌లు మరియు నెట్‌వర్క్ స్టాక్‌పై ఉంటుంది. Linux 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