વેબ એપ્લીકેશન્સ હવે દરેક જગ્યાએ ઉપયોગમાં લેવાય છે, અને તમામ ટ્રાન્સપોર્ટ પ્રોટોકોલ્સમાં, HTTP એ સિંહનો હિસ્સો ધરાવે છે. વેબ એપ્લિકેશન ડેવલપમેન્ટની ઘોંઘાટનો અભ્યાસ કરતી વખતે, મોટાભાગના લોકો ઓપરેટિંગ સિસ્ટમ પર ખૂબ ઓછું ધ્યાન આપે છે જ્યાં આ એપ્લિકેશનો ખરેખર ચાલે છે. વિકાસ (દેવ) અને કામગીરી (ઓપ્સ) ના વિભાજનથી પરિસ્થિતિ વધુ ખરાબ થઈ. પરંતુ DevOps કલ્ચરના ઉદય સાથે, ડેવલપર્સ ક્લાઉડમાં તેમની એપ્લિકેશન ચલાવવા માટે જવાબદાર બની રહ્યા છે, તેથી ઓપરેટિંગ સિસ્ટમના બેકએન્ડથી સંપૂર્ણ રીતે પરિચિત થવું તેમના માટે ખૂબ જ ઉપયોગી છે. આ ખાસ કરીને ઉપયોગી છે જો તમે હજારો અથવા હજારો એકસાથે જોડાણો માટે સિસ્ટમ જમાવવાનો પ્રયાસ કરી રહ્યાં હોવ.

વેબ સેવાઓની મર્યાદાઓ અન્ય એપ્લિકેશનોમાંની મર્યાદાઓ જેવી જ છે. ભલે તે લોડ બેલેન્સર હોય કે ડેટાબેઝ સર્વર, આ તમામ એપ્લિકેશનો ઉચ્ચ-પ્રદર્શન વાતાવરણમાં સમાન સમસ્યાઓ ધરાવે છે. આ મૂળભૂત મર્યાદાઓને સમજવી અને સામાન્ય રીતે તેને કેવી રીતે દૂર કરવી તે તમને તમારી વેબ એપ્લિકેશન્સના પ્રદર્શન અને માપનીયતાનું મૂલ્યાંકન કરવામાં મદદ કરશે.

હું આ લેખોની શ્રેણી યુવાન વિકાસકર્તાઓના પ્રશ્નોના જવાબમાં લખી રહ્યો છું જેઓ સારી રીતે જાણકાર સિસ્ટમ આર્કિટેક્ટ બનવા માંગે છે. ઓપરેટિંગ સિસ્ટમ સ્તરે કેવી રીતે કાર્ય કરે છે તેની મૂળભૂત બાબતોમાં ડાઇવ કર્યા વિના Linux એપ્લિકેશન ઑપ્ટિમાઇઝેશન તકનીકોને સ્પષ્ટપણે સમજવું અશક્ય છે. જો કે એપ્લીકેશનના ઘણા પ્રકારો છે, આ શ્રેણીમાં હું ડેસ્કટોપ એપ્લીકેશન જેમ કે બ્રાઉઝર અથવા ટેક્સ્ટ એડિટરને બદલે વેબ-આધારિત એપ્લીકેશન્સનું અન્વેષણ કરવા માંગુ છું. આ સામગ્રી વિકાસકર્તાઓ અને આર્કિટેક્ટ્સ માટે બનાવાયેલ છે જેઓ Linux અથવા Unix પ્રોગ્રામ્સ કેવી રીતે કાર્ય કરે છે અને ઉચ્ચ પ્રદર્શન માટે તેમને કેવી રીતે સ્ટ્રક્ચર કરવું તે સમજવા માંગે છે.

Linux છે સર્વર રૂમ ઓપરેટિંગ સિસ્ટમ, અને મોટાભાગે તમારી એપ્લિકેશનો આ OS પર ચાલે છે. જો કે હું "Linux" કહું છું, મોટાભાગે તમે સુરક્ષિત રીતે ધારી શકો છો કે મારો મતલબ સામાન્ય રીતે યુનિક્સ જેવી ઓપરેટિંગ સિસ્ટમ છે. જો કે, મેં અન્ય સિસ્ટમો પર સાથેના કોડનું પરીક્ષણ કર્યું નથી. તેથી, જો તમને ફ્રીબીએસડી અથવા ઓપનબીએસડીમાં રસ હોય, તો તમારા પરિણામો બદલાઈ શકે છે. જ્યારે હું Linux-વિશિષ્ટ કંઈક કરવાનો પ્રયાસ કરું છું, ત્યારે હું તેને નિર્દેશ કરું છું.

જ્યારે તમે શરૂઆતથી એપ્લિકેશન બનાવવા માટે આ જ્ઞાનનો ઉપયોગ કરી શકો છો અને તે સંપૂર્ણ રીતે ઑપ્ટિમાઇઝ કરવામાં આવશે, તે ન કરવું શ્રેષ્ઠ છે. જો તમે તમારી સંસ્થાની વ્યવસાય એપ્લિકેશન માટે C અથવા C++ માં નવું વેબ સર્વર લખો છો, તો આ નોકરી પરનો તમારો છેલ્લો દિવસ હોઈ શકે છે. જો કે, આ એપ્લીકેશનનું માળખું જાણવાથી હાલના પ્રોગ્રામ્સ પસંદ કરવામાં મદદ મળશે. તમે પ્રક્રિયા-આધારિત સિસ્ટમોની તુલના થ્રેડ-આધારિત સિસ્ટમો તેમજ ઇવેન્ટ-આધારિત સાથે કરી શકશો. તમે સમજશો અને પ્રશંસા કરશો કે શા માટે Nginx Apache httpd કરતાં વધુ સારું પ્રદર્શન કરે છે, શા માટે ટોર્નેડો આધારિત પાયથોન એપ્લિકેશન જેંગો આધારિત પાયથોન એપ્લિકેશનની તુલનામાં વધુ વપરાશકર્તાઓને સેવા આપી શકે છે.

ZeroHTTPd: શીખવાનું સાધન

ZeroHTTPd એક વેબ સર્વર છે જે મેં શીખવવાના સાધન તરીકે C માં શરૂઆતથી લખ્યું છે. તેની પાસે કોઈ બાહ્ય નિર્ભરતા નથી, જેમાં રેડિસની ઍક્સેસનો સમાવેશ થાય છે. અમે અમારી પોતાની Redis પ્રક્રિયાઓ ચલાવીએ છીએ. વધુ વિગતો માટે નીચે જુઓ.

જો કે આપણે થિયરી વિશે લંબાણપૂર્વક ચર્ચા કરી શકીએ છીએ, કોડ લખવા, તેને ચલાવવા અને સર્વર આર્કિટેક્ચરની એકબીજા સાથે સરખામણી કરવા સિવાય બીજું કંઈ નથી. આ સૌથી સ્પષ્ટ પદ્ધતિ છે. તેથી, અમે દરેક મોડેલનો ઉપયોગ કરીને એક સરળ ZeroHTTPd વેબ સર્વર લખીશું: પ્રક્રિયા-આધારિત, થ્રેડ-આધારિત અને ઇવેન્ટ-આધારિત. ચાલો આ દરેક સર્વરને તપાસીએ અને જોઈએ કે તેઓ એકબીજાની સરખામણીમાં કેવું પ્રદર્શન કરે છે. ZeroHTTPd એક જ C ફાઇલમાં લાગુ કરવામાં આવે છે. ઇવેન્ટ-આધારિત સર્વરમાં સમાવેશ થાય છે ઉતાશ, એક મહાન હેશ ટેબલ અમલીકરણ જે એક હેડર ફાઇલમાં આવે છે. અન્ય કિસ્સાઓમાં, ત્યાં કોઈ નિર્ભરતા નથી, જેથી પ્રોજેક્ટ જટિલ ન બને.

તમને સમજવામાં મદદ કરવા માટે કોડમાં ઘણી બધી ટિપ્પણીઓ છે. કોડની કેટલીક લાઇનમાં એક સરળ વેબ સર્વર હોવાને કારણે, ZeroHTTPd એ વેબ ડેવલપમેન્ટ માટે ન્યૂનતમ ફ્રેમવર્ક પણ છે. તે મર્યાદિત કાર્યક્ષમતા ધરાવે છે, પરંતુ તે સ્થિર ફાઇલો અને ખૂબ જ સરળ "ડાયનેમિક" પૃષ્ઠોને સેવા આપવા માટે સક્ષમ છે. મારે કહેવું છે કે ZeroHTTPd ઉચ્ચ-પ્રદર્શન Linux એપ્લિકેશન્સ કેવી રીતે બનાવવી તે શીખવા માટે સારું છે. મોટાભાગે, મોટાભાગની વેબ સેવાઓ વિનંતીઓની રાહ જુએ છે, તેમને તપાસે છે અને પ્રક્રિયા કરે છે. આ બરાબર છે જે ZeroHTTPd કરશે. આ શીખવાનું સાધન છે, ઉત્પાદન નહીં. ભૂલ સંભાળવામાં તે મહાન નથી અને શ્રેષ્ઠ સુરક્ષા પ્રથાઓની બડાઈ કરે તેવી શક્યતા નથી (ઓહ હા, મેં ઉપયોગ કર્યો strcpy) અથવા સી ભાષાની હોંશિયાર યુક્તિઓ. પરંતુ મને આશા છે કે તે તેનું કામ સારી રીતે કરશે.

ZeroHTTPd હોમ પેજ. તે ઈમેજીસ સહિત વિવિધ પ્રકારની ફાઈલ આઉટપુટ કરી શકે છે

ગેસ્ટ બુક એપ્લિકેશન

આધુનિક વેબ એપ્લિકેશનો સામાન્ય રીતે સ્થિર ફાઇલો સુધી મર્યાદિત હોતી નથી. તેઓ વિવિધ ડેટાબેઝ, કેશ વગેરે સાથે જટિલ ક્રિયાપ્રતિક્રિયાઓ ધરાવે છે. તેથી અમે "ગેસ્ટ બુક" નામની એક સરળ વેબ એપ્લિકેશન બનાવીશું જ્યાં મુલાકાતીઓ તેમના નામ હેઠળ પ્રવેશો છોડે છે. ગેસ્ટ બુક સ્ટોરની એન્ટ્રીઓ અગાઉ બાકી છે. પૃષ્ઠના તળિયે મુલાકાતી કાઉન્ટર પણ છે.

વેબ એપ્લિકેશન "ગેસ્ટ બુક" ZeroHTTPd

વિઝિટર કાઉન્ટર અને ગેસ્ટ બુક એન્ટ્રીઓ રેડિસમાં સંગ્રહિત છે. રેડિસ સાથેના સંદેશાવ્યવહાર માટે, પોતાની પ્રક્રિયાઓ લાગુ કરવામાં આવે છે; તે બાહ્ય પુસ્તકાલય પર આધારિત નથી. જ્યારે સાર્વજનિક રૂપે ઉપલબ્ધ અને સારી રીતે ચકાસાયેલ સોલ્યુશન્સ હોય ત્યારે હું હોમબ્રુ કોડને રોલઆઉટ કરવાનો મોટો ચાહક નથી. પરંતુ ZeroHTTPd નો ઉદ્દેશ્ય Linux પ્રદર્શન અને બાહ્ય સેવાઓની ઍક્સેસનો અભ્યાસ કરવાનો છે, જ્યારે HTTP વિનંતીઓ સેવા આપવાથી પ્રભાવની ગંભીર અસર થાય છે. અમારે અમારા દરેક સર્વર આર્કિટેક્ચરમાં રેડિસ સાથેના સંચારને સંપૂર્ણપણે નિયંત્રિત કરવું જોઈએ. કેટલાક આર્કિટેક્ચરમાં અમે બ્લોકિંગ કૉલ્સનો ઉપયોગ કરીએ છીએ, અન્યમાં અમે ઇવેન્ટ-આધારિત પ્રક્રિયાઓનો ઉપયોગ કરીએ છીએ. બાહ્ય Redis ક્લાયંટ લાઇબ્રેરીનો ઉપયોગ આ નિયંત્રણ પ્રદાન કરશે નહીં. વધુમાં, અમારું નાનું રેડિસ ક્લાયંટ માત્ર થોડા કાર્યો કરે છે (કી મેળવવી, સેટ કરવી અને વધારો; મેળવવી અને એરેમાં જોડવું). વધુમાં, Redis પ્રોટોકોલ અત્યંત ભવ્ય અને સરળ છે. તમારે તેને ખાસ શીખવવાની પણ જરૂર નથી. હકીકત એ છે કે પ્રોટોકોલ કોડની લગભગ સો લીટીઓમાં તમામ કાર્ય કરે છે તે દર્શાવે છે કે તે કેટલું સારી રીતે વિચાર્યું છે.

નીચેનો આંકડો બતાવે છે કે જ્યારે ક્લાયંટ (બ્રાઉઝર) વિનંતી કરે છે ત્યારે એપ્લિકેશન શું કરે છે /guestbookURL.

ગેસ્ટ બુક એપ્લિકેશન કેવી રીતે કાર્ય કરે છે

જ્યારે ગેસ્ટ બુક પેજ જારી કરવાની જરૂર હોય, ત્યારે ટેમ્પલેટને મેમરીમાં વાંચવા માટે ફાઇલ સિસ્ટમને એક કૉલ અને Redisને ત્રણ નેટવર્ક કૉલ્સ કરવામાં આવે છે. ટેમ્પલેટ ફાઇલમાં ઉપરના સ્ક્રીનશોટમાંના પૃષ્ઠ માટે મોટાભાગની HTML સામગ્રી શામેલ છે. સામગ્રીના ગતિશીલ ભાગ માટે વિશેષ પ્લેસહોલ્ડર્સ પણ છે: પોસ્ટ્સ અને વિઝિટર કાઉન્ટર. અમે તેમને 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-અક્ષ એ સેકન્ડ દીઠ વિનંતીઓની સંખ્યા છે, 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 થી વધુ એકસાથે વિનંતીઓ માટે અમારી પાસે ફક્ત બે જ ખેલાડીઓ બાકી છે: પ્રી-ફોર્ક અને ઇપોલ. જેમ જેમ લોડ વધે છે, મતદાન-આધારિત સર્વર સ્ટ્રીમિંગ કરતાં વધુ ખરાબ પ્રદર્શન કરે છે. થ્રેડ-પ્રી-ક્રિએશન આર્કિટેક્ચર એ ઇપોલ માટે લાયક હરીફ છે, જે Linux કર્નલ મોટી સંખ્યામાં થ્રેડોને કેટલી સારી રીતે સુનિશ્ચિત કરે છે તેનો પ્રમાણપત્ર છે.

ZeroHTTPd સોર્સ કોડ

ZeroHTTPd સોર્સ કોડ અહીં. દરેક આર્કિટેક્ચર માટે અલગ ડિરેક્ટરી છે.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_ફોર્કિંગ │ ├── main.c ├── main.c ├── 03_preforking ├── main. 04_ થ્રેડીંગ │ ├── main.c ├── 05_પ્રીથ્રેડિંગ │ ├── main.c ├── 06_પોલ │ ├── main.c ├── 07_epoll │ │ └── main.c ├ જાહેર કરો ├── અનુક્રમણિકા .html │ └── ટક્સ 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 સંસાધનોની જરૂર છે. પરંતુ મોટાભાગની એપ્લિકેશનો માટે આ કેસ નથી.

સર્વર આર્કિટેક્ચર વિશે વધુ જાણો

1. ભાગ I: પુનરાવર્તિત આર્કિટેક્ચર
2. ભાગ II. ફોર્ક સર્વર્સ
3. ભાગ III. પ્રી-ફોર્ક સર્વર્સ
4. ભાગ IV. અમલના થ્રેડો સાથે સર્વર્સ
5. ભાગ V. પ્રી-થ્રેડેડ સર્વર્સ
6. ભાગ VI. પોલ આધારિત આર્કિટેક્ચર
7. ભાગ VII. ઇપોલ આધારિત આર્કિટેક્ચર

સોર્સ: www.habr.com