ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹੁਣ ਹਰ ਥਾਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਸਾਰੇ ਟਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ, HTTP ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੈ। ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ ਦੀਆਂ ਬਾਰੀਕੀਆਂ ਦਾ ਅਧਿਐਨ ਕਰਦੇ ਸਮੇਂ, ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵੱਲ ਬਹੁਤ ਘੱਟ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਜਿੱਥੇ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਚੱਲਦੀਆਂ ਹਨ। ਵਿਕਾਸ (ਦੇਵ) ਅਤੇ ਸੰਚਾਲਨ (ਓਪਸ) ਦੇ ਵੱਖ ਹੋਣ ਨੇ ਸਥਿਤੀ ਨੂੰ ਹੋਰ ਬਦਤਰ ਬਣਾਇਆ ਹੈ। ਪਰ DevOps ਕਲਚਰ ਦੇ ਉਭਾਰ ਦੇ ਨਾਲ, ਡਿਵੈਲਪਰ ਕਲਾਉਡ ਵਿੱਚ ਆਪਣੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਬਣ ਰਹੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਬੈਕਐਂਡ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਹੋਣਾ ਬਹੁਤ ਲਾਭਦਾਇਕ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਹਜ਼ਾਰਾਂ ਜਾਂ ਹਜ਼ਾਰਾਂ ਸਮਕਾਲੀ ਕੁਨੈਕਸ਼ਨਾਂ ਲਈ ਇੱਕ ਸਿਸਟਮ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ।

ਵੈੱਬ ਸੇਵਾਵਾਂ ਵਿੱਚ ਸੀਮਾਵਾਂ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਸਮਾਨ ਹਨ। ਭਾਵੇਂ ਇਹ ਲੋਡ ਬੈਲੈਂਸਰ ਜਾਂ ਡੇਟਾਬੇਸ ਸਰਵਰ ਹਨ, ਇਹਨਾਂ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਇਹਨਾਂ ਬੁਨਿਆਦੀ ਸੀਮਾਵਾਂ ਨੂੰ ਸਮਝਣਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਦੂਰ ਕਰਨਾ ਹੈ, ਤੁਹਾਨੂੰ ਤੁਹਾਡੀਆਂ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਮਾਪਯੋਗਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।

ਮੈਂ ਨੌਜਵਾਨ ਡਿਵੈਲਪਰਾਂ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਵਿੱਚ ਲੇਖਾਂ ਦੀ ਇਹ ਲੜੀ ਲਿਖ ਰਿਹਾ ਹਾਂ ਜੋ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਸਿਸਟਮ ਆਰਕੀਟੈਕਟ ਬਣਨਾ ਚਾਹੁੰਦੇ ਹਨ। ਲੀਨਕਸ ਐਪਲੀਕੇਸ਼ਨ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਤਕਨੀਕਾਂ ਨੂੰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਇਸ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ ਵਿੱਚ ਗੋਤਾਖੋਰ ਕੀਤੇ ਬਿਨਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਝਣਾ ਅਸੰਭਵ ਹੈ। ਹਾਲਾਂਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ ਹਨ, ਇਸ ਲੜੀ ਵਿੱਚ ਮੈਂ ਡੈਸਕਟੌਪ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜਿਵੇਂ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ ਟੈਕਸਟ ਐਡੀਟਰ ਦੀ ਬਜਾਏ ਵੈਬ-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਖੋਜ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਇਹ ਸਮੱਗਰੀ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਆਰਕੀਟੈਕਟਾਂ ਲਈ ਹੈ ਜੋ ਇਹ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਲੀਨਕਸ ਜਾਂ ਯੂਨਿਕਸ ਪ੍ਰੋਗਰਾਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹਨ।

ਲੀਨਕਸ ਹੈ ਸਰਵਰ ਰੂਮ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇਸ OS 'ਤੇ ਚੱਲਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ ਮੈਂ "ਲੀਨਕਸ" ਕਹਿੰਦਾ ਹਾਂ, ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਇਹ ਮੰਨ ਸਕਦੇ ਹੋ ਕਿ ਮੇਰਾ ਮਤਲਬ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰੇ ਯੂਨਿਕਸ-ਵਰਗੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਹਨ। ਹਾਲਾਂਕਿ, ਮੈਂ ਦੂਜੇ ਸਿਸਟਮਾਂ 'ਤੇ ਨਾਲ ਵਾਲੇ ਕੋਡ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਇਸ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ FreeBSD ਜਾਂ OpenBSD ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਨਤੀਜੇ ਵੱਖੋ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਮੈਂ ਲੀਨਕਸ-ਵਿਸ਼ੇਸ਼ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਮੈਂ ਇਸਨੂੰ ਦਰਸਾਉਂਦਾ ਹਾਂ.

ਹਾਲਾਂਕਿ ਤੁਸੀਂ ਸਕ੍ਰੈਚ ਤੋਂ ਇੱਕ ਐਪ ਬਣਾਉਣ ਲਈ ਇਸ ਗਿਆਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾਵੇਗਾ, ਅਜਿਹਾ ਨਾ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੀ ਸੰਸਥਾ ਦੀ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ C ਜਾਂ C++ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਵੈੱਬ ਸਰਵਰ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਇਹ ਨੌਕਰੀ 'ਤੇ ਤੁਹਾਡਾ ਆਖਰੀ ਦਿਨ ਹੋ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਬਣਤਰ ਨੂੰ ਜਾਣਨਾ ਮੌਜੂਦਾ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਚੋਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਤੁਸੀਂ ਪ੍ਰਕਿਰਿਆ-ਅਧਾਰਤ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਥਰਿੱਡ-ਅਧਾਰਤ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਾਲ ਨਾਲ ਇਵੈਂਟ-ਅਧਾਰਤ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੋਗੇ। ਤੁਸੀਂ ਸਮਝੋਗੇ ਅਤੇ ਪ੍ਰਸ਼ੰਸਾ ਕਰੋਗੇ ਕਿ Nginx ਅਪਾਚੇ httpd ਨਾਲੋਂ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਿਉਂ ਕਰਦਾ ਹੈ, ਕਿਉਂ ਇੱਕ ਟੋਰਨਾਡੋ ਅਧਾਰਤ ਪਾਈਥਨ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ Django ਅਧਾਰਤ ਪਾਈਥਨ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਵਧੇਰੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰ ਸਕਦੀ ਹੈ।

ZeroHTTPd: ਲਰਨਿੰਗ ਟੂਲ

ZeroHTTPd ਇੱਕ ਵੈਬ ਸਰਵਰ ਹੈ ਜੋ ਮੈਂ ਇੱਕ ਅਧਿਆਪਨ ਟੂਲ ਵਜੋਂ C ਵਿੱਚ ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖਿਆ ਹੈ। ਇਸਦੀ ਕੋਈ ਬਾਹਰੀ ਨਿਰਭਰਤਾ ਨਹੀਂ ਹੈ, Redis ਤੱਕ ਪਹੁੰਚ ਸਮੇਤ। ਅਸੀਂ ਆਪਣੀਆਂ ਖੁਦ ਦੀਆਂ Redis ਪ੍ਰਕਿਰਿਆਵਾਂ ਚਲਾਉਂਦੇ ਹਾਂ। ਹੋਰ ਵੇਰਵਿਆਂ ਲਈ ਹੇਠਾਂ ਦੇਖੋ।

ਹਾਲਾਂਕਿ ਅਸੀਂ ਥਿਊਰੀ ਦੀ ਲੰਬਾਈ 'ਤੇ ਚਰਚਾ ਕਰ ਸਕਦੇ ਹਾਂ, ਕੋਡ ਲਿਖਣਾ, ਇਸਨੂੰ ਚਲਾਉਣਾ, ਅਤੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਾਰੇ ਸਰਵਰ ਆਰਕੀਟੈਕਚਰ ਦੀ ਤੁਲਨਾ ਕਰਨ ਨਾਲੋਂ ਬਿਹਤਰ ਕੁਝ ਨਹੀਂ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਤਰੀਕਾ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਹਰੇਕ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਸਧਾਰਨ ZeroHTTPd ਵੈੱਬ ਸਰਵਰ ਲਿਖਾਂਗੇ: ਪ੍ਰਕਿਰਿਆ-ਅਧਾਰਿਤ, ਥ੍ਰੈਡ-ਅਧਾਰਿਤ, ਅਤੇ ਇਵੈਂਟ-ਅਧਾਰਿਤ। ਆਉ ਇਹਨਾਂ ਸਰਵਰਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਦੀ ਜਾਂਚ ਕਰੀਏ ਅਤੇ ਵੇਖੀਏ ਕਿ ਉਹ ਇੱਕ ਦੂਜੇ ਦੇ ਮੁਕਾਬਲੇ ਕਿਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ। ZeroHTTPd ਇੱਕ ਸਿੰਗਲ C ਫਾਈਲ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਵੈਂਟ-ਅਧਾਰਿਤ ਸਰਵਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ uthash, ਇੱਕ ਵਧੀਆ ਹੈਸ਼ ਟੇਬਲ ਲਾਗੂ ਕਰਨਾ ਜੋ ਇੱਕ ਸਿੰਗਲ ਹੈਡਰ ਫਾਈਲ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਦੂਜੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਕੋਈ ਨਿਰਭਰਤਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਜੋ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਗੁੰਝਲਦਾਰ ਨਾ ਬਣਾਇਆ ਜਾ ਸਕੇ।

ਤੁਹਾਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਕੋਡ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਟਿੱਪਣੀਆਂ ਹਨ। ਕੋਡ ਦੀਆਂ ਕੁਝ ਲਾਈਨਾਂ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਵੈੱਬ ਸਰਵਰ ਹੋਣ ਦੇ ਨਾਤੇ, ZeroHTTPd ਵੈੱਬ ਵਿਕਾਸ ਲਈ ਇੱਕ ਨਿਊਨਤਮ ਫਰੇਮਵਰਕ ਵੀ ਹੈ। ਇਸ ਵਿੱਚ ਸੀਮਤ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੈ, ਪਰ ਇਹ ਸਥਿਰ ਫਾਈਲਾਂ ਅਤੇ ਬਹੁਤ ਹੀ ਸਧਾਰਨ "ਗਤੀਸ਼ੀਲ" ਪੰਨਿਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ। ਮੈਨੂੰ ਇਹ ਕਹਿਣਾ ਹੈ ਕਿ ZeroHTTPd ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ ਲੀਨਕਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ ਇਹ ਸਿੱਖਣ ਲਈ ਵਧੀਆ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ, ਜ਼ਿਆਦਾਤਰ ਵੈਬ ਸੇਵਾਵਾਂ ਬੇਨਤੀਆਂ ਦੀ ਉਡੀਕ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ZeroHTTPd ਕਰੇਗਾ. ਇਹ ਸਿੱਖਣ ਦਾ ਸਾਧਨ ਹੈ, ਉਤਪਾਦਨ ਨਹੀਂ। ਇਹ ਗਲਤੀ ਨਾਲ ਨਜਿੱਠਣ ਵਿੱਚ ਵਧੀਆ ਨਹੀਂ ਹੈ ਅਤੇ ਵਧੀਆ ਸੁਰੱਖਿਆ ਅਭਿਆਸਾਂ ਦੀ ਸ਼ੇਖੀ ਮਾਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ (ਓ ਹਾਂ, ਮੈਂ ਵਰਤਿਆ strcpy) ਜਾਂ C ਭਾਸ਼ਾ ਦੀਆਂ ਚਲਾਕ ਚਾਲਾਂ। ਪਰ ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਆਪਣਾ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰੇਗੀ।

ZeroHTTPd ਹੋਮ ਪੇਜ। ਇਹ ਚਿੱਤਰਾਂ ਸਮੇਤ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰ ਸਕਦਾ ਹੈ

ਗੈਸਟ ਬੁੱਕ ਐਪਲੀਕੇਸ਼ਨ

ਆਧੁਨਿਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਰ ਫਾਈਲਾਂ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਦਾ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ, ਕੈਚਾਂ ਆਦਿ ਨਾਲ ਗੁੰਝਲਦਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ। ਇਸਲਈ ਅਸੀਂ "ਗੈਸਟ ਬੁੱਕ" ਨਾਮਕ ਇੱਕ ਸਧਾਰਨ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਵਾਂਗੇ ਜਿੱਥੇ ਸੈਲਾਨੀ ਆਪਣੇ ਨਾਮ ਹੇਠ ਐਂਟਰੀਆਂ ਛੱਡਦੇ ਹਨ। ਗੈਸਟ ਬੁੱਕ ਸਟੋਰ ਐਂਟਰੀਆਂ ਪਹਿਲਾਂ ਛੱਡੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਪੰਨੇ ਦੇ ਹੇਠਾਂ ਇੱਕ ਵਿਜ਼ਟਰ ਕਾਊਂਟਰ ਵੀ ਹੈ।

ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ "ਗੈਸਟ ਬੁੱਕ" ZeroHTTPd

ਵਿਜ਼ਟਰ ਕਾਊਂਟਰ ਅਤੇ ਗੈਸਟ ਬੁੱਕ ਐਂਟਰੀਆਂ Redis ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। Redis ਨਾਲ ਸੰਚਾਰ ਲਈ, ਆਪਣੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ; ਉਹ ਬਾਹਰੀ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਂਚੇ ਗਏ ਹੱਲ ਹੋਣ ਤਾਂ ਮੈਂ ਹੋਮਬਰੂ ਕੋਡ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਦਾ ਵੱਡਾ ਪ੍ਰਸ਼ੰਸਕ ਨਹੀਂ ਹਾਂ। ਪਰ ZeroHTTPd ਦਾ ਉਦੇਸ਼ ਲੀਨਕਸ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਹੈ, ਜਦੋਂ ਕਿ HTTP ਬੇਨਤੀਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਨਾਲ ਇੱਕ ਗੰਭੀਰ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ। ਸਾਨੂੰ ਸਾਡੇ ਹਰੇਕ ਸਰਵਰ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ 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-ਧੁਰਾ ਪ੍ਰਤੀ ਸਕਿੰਟ ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ ਹੈ, 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_Iterative │ ├── main.c ├── 02_ਫੋਰਕਿੰਗ │ ├── main.c ├── main.c ├── 03_preforking ├── main.c ├── 04_preforking ├── 05_ ਥ੍ਰੈਡਿੰਗ │ ├── main.c ├── 06_ਪ੍ਰੀਥ੍ਰੈਡਿੰਗ │ ├── main.c ├── 07_poll │ ├── main.c ├── XNUMX_epoll │ └── main.c ├├─le─ ਮੇਨ. ├── ਸੂਚਕਾਂਕ .html │ └── ਟਕਸ . png └── ਟੈਂਪਲੇਟਸ └── ਮਹਿਮਾਨ ਪੁਸਤਕ └── index.html

ਸਾਰੇ ਆਰਕੀਟੈਕਚਰ ਲਈ ਸੱਤ ਡਾਇਰੈਕਟਰੀਆਂ ਤੋਂ ਇਲਾਵਾ, ਉੱਚ-ਪੱਧਰੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਦੋ ਹੋਰ ਹਨ: ਜਨਤਕ ਅਤੇ ਟੈਂਪਲੇਟਸ। ਪਹਿਲੇ ਵਿੱਚ index.html ਫਾਈਲ ਅਤੇ ਪਹਿਲੇ ਸਕ੍ਰੀਨਸ਼ੌਟ ਤੋਂ ਚਿੱਤਰ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਉੱਥੇ ਹੋਰ ਫਾਈਲਾਂ ਅਤੇ ਫੋਲਡਰਾਂ ਨੂੰ ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ZeroHTTPd ਨੂੰ ਉਹਨਾਂ ਸਥਿਰ ਫਾਈਲਾਂ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਸਰਵ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਜੇਕਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਮਾਰਗ ਜਨਤਕ ਫੋਲਡਰ ਵਿੱਚ ਮਾਰਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ZeroHTTPd ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ index.html ਫਾਈਲ ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ। ਗੈਸਟ ਬੁੱਕ ਲਈ ਸਮੱਗਰੀ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਹੋਮ ਪੇਜ ਹੈ, ਅਤੇ ਇਸਦੀ ਸਮੱਗਰੀ 'templates/guestbook/index.html' 'ਤੇ ਆਧਾਰਿਤ ਹੈ। ZeroHTTPd ਐਕਸਟੈਂਸ਼ਨ ਲਈ ਡਾਇਨਾਮਿਕ ਪੰਨਿਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਟੈਂਪਲੇਟ ਜੋੜ ਸਕਦੇ ਹਨ ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ZeroHTTPd ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਨ।

ਸਾਰੇ ਸੱਤ ਸਰਵਰ ਬਣਾਉਣ ਲਈ, ਚਲਾਓ make all ਸਿਖਰ-ਪੱਧਰ ਦੀ ਡਾਇਰੈਕਟਰੀ ਤੋਂ - ਅਤੇ ਸਾਰੇ ਬਿਲਡ ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣਗੇ। ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਉਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਪਬਲਿਕ ਅਤੇ ਟੈਂਪਲੇਟ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਲੱਭਦੀਆਂ ਹਨ ਜਿੱਥੋਂ ਉਹ ਲਾਂਚ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਲੀਨਕਸ API

ਇਸ ਲੇਖ ਲੜੀ ਵਿੱਚ ਜਾਣਕਾਰੀ ਨੂੰ ਸਮਝਣ ਲਈ ਤੁਹਾਨੂੰ ਲੀਨਕਸ API ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਹਾਲਾਂਕਿ, ਮੈਂ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਹੋਰ ਪੜ੍ਹਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ; ਇੰਟਰਨੈਟ ਤੇ ਬਹੁਤ ਸਾਰੇ ਸੰਦਰਭ ਸਰੋਤ ਹਨ. ਹਾਲਾਂਕਿ ਅਸੀਂ ਲੀਨਕਸ API ਦੀਆਂ ਕਈ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਛੂਹਾਂਗੇ, ਸਾਡਾ ਫੋਕਸ ਮੁੱਖ ਤੌਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਥਰਿੱਡਾਂ, ਇਵੈਂਟਾਂ, ਅਤੇ ਨੈੱਟਵਰਕ ਸਟੈਕ 'ਤੇ ਹੋਵੇਗਾ। ਲੀਨਕਸ 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