سرور کا بوجھ کم کرنا

اس مضمون میں، ہم اس بات کا جائزہ لیں گے کہ سرور کا بوجھ کیوں بڑھتا ہے اور زیادہ بوجھ کے عمل کو بہتر بنانے کے مختلف طریقوں پر تبادلہ خیال کریں گے۔ Apache/Nginx اور MySQL میں کوڈ کی اصلاح پر خصوصی توجہ دی جائے گی، ہم ایک معاون ٹول کے طور پر کیشنگ کے بارے میں بات کریں گے، اور ممکنہ بیرونی خطرات، جیسے DDOS حملوں، اور ان کو روکنے کے طریقوں پر بھی غور کریں گے۔

سرور لوڈ کیوں ہوتا ہے۔

سرور کی اصلاح پر آگے بڑھنے سے پہلے، وسائل پر موجودہ بوجھ کا مکمل تجزیہ کرنا ضروری ہے۔ اس میں CPU لوڈ، RAM کا استعمال، نیٹ ورک کی سرگرمی، اور دیگر کلیدی پیرامیٹرز کی پیمائش شامل ہے۔ حرکیات اور چوٹی کے بوجھ کو سمجھنا رکاوٹوں کی نشاندہی کرنے اور وسائل کی تقسیم کو بہتر بنانے کی اجازت دیتا ہے، اس طرح سرور کے بنیادی ڈھانچے کے استحکام اور کارکردگی میں اضافہ ہوتا ہے۔

زیادہ سرور لوڈ کی ابتدائی خرابیوں کا سراغ لگانے کے لیے، ہم تجویز کرتے ہیں کہ ایک عام سرور کی تشخیص. اگر یہ ناکافی ہے تو مزید تفصیلی وسائل کا تجزیہ ضروری ہے. ایک معاون آلے کے طور پر، کی تلاش لینکس کے لاگز سرور مددگار ثابت ہوسکتا ہے، کیونکہ یہ وہ جگہ ہے جہاں زیادہ تر معاملات میں مسئلہ کا ذریعہ پایا جاتا ہے۔

Apache/Nginx سرور کو بہتر بنانا

انڈیکسنگ کی وجہ سے سرور لوڈ میں اضافہ

سرور پر انڈیکسنگ کی وجہ سے بوجھ میں اضافہ ہو سکتا ہے، مثال کے طور پر، جب سرچ انجن آپ کی سائٹ پر صفحات کی ایک بڑی تعداد کو اسکین کرتے ہیں۔ اس سے سرور کے وسائل کے استعمال میں اضافہ ہو سکتا ہے اور اس کے نتیجے میں سائٹ کی کارکردگی سست ہو سکتی ہے۔ وجہ کی شناخت نسبتاً آسان ہے۔ آپ کو اس پر موجود فائل کو کھولنے کی ضرورت ہے:

/var/www/httpd-logs/sitename.access.log

جب سرچ انجنوں کے ذریعے انڈیکس کیا جائے گا، صارف کو درج ذیل نوعیت کے اندراجات نظر آئیں گے:

11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

بوجھ کو کم کرنے کے پہلے حل کے طور پر، آپ میٹا ٹیگز کی ترتیب استعمال کر سکتے ہیں۔ "noindex" اور "nofollow" ان صفحات پر جن کو انڈیکس کرنے کی ضرورت نہیں ہے۔ دوسرا حل یہ ہے۔ htaccess. فائل، جہاں مخصوص سرچ انجنوں سے متعلق اندراجات کو شامل کرنے کی ضرورت ہے، مثال کے طور پر، Yandex اور Google سے چھپانے کے لیے:

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

اسی طرح، دوسرے سرچ انجنوں کے لیے بھی ترمیم کرنے کی ضرورت ہے۔ واضح رہے کہ .htaccess کی صلاحیتیں صرف انڈیکسنگ کو بلاک کرنے تک محدود نہیں ہیں۔ ہم میں اس کی اہم خصوصیات سے مزید واقف ہونے کی تجویز کرتے ہیں۔ مضمون.

کیشنگ سیٹنگز کا استعمال کرنا

سرور پر کیشنگ کی غلط ترتیبات بھی زیادہ بوجھ کا باعث بن سکتی ہیں۔ اس پیرامیٹر کو بہتر بنانے کے لیے، کنفیگریشن فائلوں میں متعلقہ تبدیلیاں کرنے کی ضرورت ہے یا htaccess.. اپاچی کے معاملے میں، مؤخر الذکر آپشن افضل ہے، Nginx کے لیے - سابقہ۔

پر ایک اپاچی سرور، آپ کو کھولنے کی ضرورت ہے .htacess فائل کریں اور درج ذیل کوڈ داخل کریں:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

پھر، فعال کریں میعاد ختم ہوجاتی ہے کمانڈ کا استعمال کرتے ہوئے ماڈیول:

sudo a2enmod expires

اس کے بعد، ویب سرور کو دوبارہ شروع کریں:

sudo service apache2 restart

اور یہ بتا کر ماڈیول کو چالو کریں:

ExpiresActive On

پر نگنکس سرور، کنفیگریشن فائل میں درج ذیل کوڈ کو شامل کرنا کافی ہے۔

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

اور سروس دوبارہ لوڈ کریں:

sudo service nginx restart

نوٹ کریں کہ ان ترتیبات کے ساتھ، اجازت دیں اور انکار ہدایات کو نظرانداز کیا جائے گا۔

ڈیٹا کمپریشن کا استعمال

استعمال کرتے ہوئے ڈیٹا کمپریشن کو فعال کرنا Gzip Apache اور Nginx ویب سرورز پر سرور اور کلائنٹ کے درمیان منتقل ہونے والے ڈیٹا کی مقدار کو کم کرنے میں مدد کرتا ہے، جس سے کارکردگی بہتر ہوتی ہے اور ویب پیج لوڈ ہونے کا وقت کم ہوتا ہے۔

چالو کرنے کے لئے Gzip on اپاچی، آپ کو چالو کرنے کی ضرورت ہے۔ mod_deflate ماڈیول:

sudo a2enmod deflate

پھر، ویب سرور کو دوبارہ شروع کریں:

sudo service apache2 restart

اور آخر میں، مندرجہ ذیل بلاک کو کنفیگریشن فائل یا .htaccess میں شامل کریں:

<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json

# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html

# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>

یہ ترتیب مخصوص قسم کی فائلوں کے لیے کمپریشن کو قابل بناتی ہے اور اسے تصاویر کے لیے غیر فعال کر دیتی ہے۔

کی صورت میں نگنکس, ترتیب میں پایا جاتا ہے HTTP کنفیگریشن فائل کا بلاک۔ درج ذیل کوڈ کو شامل کرنے کی ضرورت ہے:

gzip on;
gzip_disable "msie6";

# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;

# Enables compression for any proxy servers
gzip_proxied any;

# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;

# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;

# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;

# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

اسی طرح اپاچی، یہاں مخصوص قسم کی فائلوں کے لیے کمپریشن پیرامیٹرز سیٹ کیے گئے ہیں۔ کسی بھی ویب سرور میں تبدیلیاں کرنے کے بعد، سروس کو دوبارہ لوڈ کرنے کی ضرورت ہے:

sudo service apache2 restart

Or

sudo service nginx restart

سرور پر DDOS حملہ

DDoS حملے کے نتیجے میں سرور کا زیادہ بوجھ ہو سکتا ہے۔ DDoS حملے کی موجودگی کی نشاندہی ٹریفک میں اچانک اضافے، غیر معمولی درخواستوں، اور سرور کی کارکردگی میں کمی کی نگرانی کے ذریعے کی جا سکتی ہے۔ ایک آئی پی ایڈریس یا پورٹ اسکیننگ سے بار بار درخواستوں کے لیے لاگز کا جائزہ لینا بھی ممکنہ DDoS حملے کی نشاندہی کر سکتا ہے۔ تحفظ کے بہت سے اقدامات ہیں، لیکن ہم صرف بنیادی باتوں پر بات کریں گے۔

CDN (مواد کی ترسیل کے نیٹ ورک) کا استعمال. ایک CDN آپ کے ویب سرور اور صارفین کے درمیان ایک ثالث کے طور پر کام کر سکتا ہے، ٹریفک کی تقسیم اور DDoS حملے کے اثرات کو کم کرنے کے لیے مواد کیشنگ کر سکتا ہے۔ CDNs میں بلٹ ان DDoS پروٹیکشن میکانزم بھی ہو سکتا ہے، بشمول لوڈ ڈسٹری بیوشن اور ٹریفک فلٹرنگ۔

فائر وال اور مداخلت کا پتہ لگانے کے نظام کو ترتیب دینا (IDS/IPS). فائر والز کو مختلف معیارات، جیسے کہ آئی پی ایڈریسز اور پورٹس کی بنیاد پر ٹریفک کو فلٹر کرنے کے لیے ترتیب دیا جا سکتا ہے۔ IDS/IPS ٹریفک کے غیر معمولی رویے کا پتہ لگا سکتا ہے اور مشکوک کنکشن کو روک سکتا ہے۔ یہ ٹولز ممکنہ طور پر بدنیتی پر مبنی ٹریفک کو ٹریک کرنے اور روکنے میں موثر ثابت ہو سکتے ہیں۔

DDoS حملوں کے اثرات کو کم کرنے کے لیے Apache اور Nginx ویب سرورز کو ترتیب دینا۔

اپاچی کے حل کے طور پر، ہم فعال کرتے ہیں۔ mod_evasive ماڈیول ایسا کرنے کے لیے، کمنٹ کریں یا درج ذیل لائن میں شامل کریں۔ httpd.conf or apache2.conf ترتیب فائل:

LoadModule evasive20_module modules/mod_evasive.so

اسی فائل میں، آپ کو ایک سیٹنگ بلاک شامل کرنے کی ضرورت ہے:

<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097

# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1

# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1

# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>

اسی طرح، ہم چالو کرتے ہیں mod_ratelimit ماڈیول:

LoadModule ratelimit_module modules/mod_ratelimit.so

اور ترتیب شامل کریں:

<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT

# Beginning of the settings block for the location "/login"
<Location "/login">

# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1

# Ending of the settings block for the location "/login"
</Location>
</IfModule>

کے لیے ترتیب نگنکس کی طرح ہے اپاچی. میں nginx.conf کنفیگریشن فائل میں درج ذیل ہدایات کو استعمال کرنے کی ضرورت ہے۔

http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;

# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

server {
        ...
        # Configuring connection limits
        limit_conn addr 10;

        # Configuring request limits
        limit_req zone=req_zone burst=5;

        ...
    }
}

ہر ایک خدمات میں تبدیلیاں کرنے کے بعد، انہیں دوبارہ لوڈ کرنے کی ضرورت ہے:

sudo systemctl restart apache2

یا:

sudo systemctl restart nginx

یہ مثالیں صرف ایک بنیادی ترتیب فراہم کرتی ہیں، جسے مخصوص ضروریات اور حملوں کی نوعیت کے لحاظ سے مزید ڈھالا جا سکتا ہے۔

MySQL سوالات کو بہتر بنانا

ویب سرور پر MySQL ڈیٹا بیس کے استفسارات کو بہتر بنانا مختلف طریقوں سے حاصل کیا جا سکتا ہے، اور ان میں سے ایک کنفیگریشن فائل کی مناسب ترتیب ہے۔ عام طور پر، اس فائل کو نام دیا جاتا ہے۔ my.cnf or my.ini اور میں واقع ہے / وغیرہ / or /etc/mysql/ ڈائریکٹری آپ کو اسے کھولنے اور درج ذیل تبدیلیاں کرنے کی ضرورت ہے:

[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log

# Threshold time for considering slow queries (in seconds)
long_query_time = 5

# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1

# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M

# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M

# Size of the thread cache
thread_cache_size = 16

# Disabling name resolving
skip-name-resolve = 1

# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M

# Size of the InnoDB log file
innodb_log_file_size = 200M

آئیے اضافی سفارشات پر بھی غور کریں جو سرور ڈیٹا بیس کے ساتھ تعامل کو آسان بنا سکتی ہیں:

1. استعمال کریں وضاحت ایس کیو ایل کے استفسار سے پہلے اس کے عمل کا تجزیہ کرنے کے لیے کمانڈ کریں۔ یہ آپ کو استفسار کے لیے عمل درآمد کا منصوبہ حاصل کرنے اور اس بات کا تعین کرنے کی اجازت دیتا ہے کہ کون سے اشاریہ جات استعمال کیے گئے ہیں، کون سے ٹیبلز کو اسکین کیا گیا ہے، وغیرہ۔
2. اشاریہ جات ڈیٹا کی تلاش کو تیز کرتے ہیں، اس لیے مناسب طریقے سے ڈیزائن کیے گئے اشاریہ جات استفسار کی کارکردگی کو نمایاں طور پر بہتر بنا سکتے ہیں۔ ان کالموں پر توجہ دیں جو اکثر استعمال ہوتے ہیں۔ کہاں or شمولیت شروط.
3. استعمال کرنے سے گریز کریں منتخب کریں *. کسی ٹیبل میں تمام کالموں کو منتخب کرنے کے بجائے صرف ان کالموں کی وضاحت کریں جو آپ کے استفسار کے لیے واقعی ضروری ہیں۔
4. میں فنکشنز استعمال کرنے سے گریز کریں۔ کہاں حالات افعال کا استعمال کرتے ہوئے (جیسے کم, UPPER, LEFT, RIGHT) میں کہاں حالات اشاریہ جات کو بیکار بنا سکتے ہیں۔ حالات میں ان کے براہ راست استعمال سے بچنے کی کوشش کریں۔
5. استعمال اندرونی شرکت جہاں ممکن ہو، کیونکہ یہ عام طور پر زیادہ موثر ہوتا ہے۔ نیز، اس بات کو یقینی بنائیں کہ شامل ہونے کے لیے متعلقہ کالموں میں اشاریہ جات ہیں۔
6. استعمال LIMIT اگر آپ کو صرف ایک مخصوص تعداد میں نتائج حاصل کرنے کی ضرورت ہو تو واپس آنے والی قطاروں کی تعداد کو محدود کرنے کے لیے۔
7. کیشنگ استفسار کے نتائج پر غور کریں، خاص طور پر اگر وہ شاذ و نادر ہی تبدیل ہوتے ہیں، سرور کا بوجھ کم کرنے کے لیے۔

میل سرور سرور پر زیادہ بوجھ پیدا کرتا ہے۔

اس سیکشن میں، ہم اس بات کا پتہ لگائیں گے کہ میل سرور زیادہ بوجھ کا سامنا کر رہا ہے اور اس کے آپریشن کو بہتر بنانے کے لیے کیا اقدامات کیے جا سکتے ہیں، بشمول پیغام کی قطار کی جانچ کرنا اور سرور کے پیرامیٹرز کو ترتیب دینا۔ پیغام کی قطار کی جانچ کے ساتھ شروع کریں۔ دی mailq یوٹیلیٹی اس میں مدد کر سکتی ہے، اسے چالو کرنے کے لیے، ٹرمینل میں متعلقہ کمانڈ درج کریں:

mailq

یہ قطار میں پیغامات کی فہرست دکھائے گا، اگر کوئی ہے۔ ہر پیغام کو اس کے منفرد شناخت کنندہ اور بھیجنے کی حیثیت کے بارے میں معلومات کے ساتھ دکھایا جائے گا۔ میل کلائنٹ لاگز کا جائزہ لے کر بھی ایسا ہی نتیجہ حاصل کیا جا سکتا ہے۔

زیادہ تر معاملات میں، سرور سے سمجھوتہ ہونے کی صورت میں زیادہ بوجھ اس وقت ہوتا ہے جب یہ سپیم بھیجنا شروع کر دیتا ہے۔ تاہم، اگر چیک کرنے کے بعد ایڈمنسٹریٹر کو یقین ہے کہ سرور پر باہر سے حملہ نہیں ہوا ہے اور صارف اسپام کو نظر انداز نہیں کر رہے ہیں، تو یہ وقت ہے کہ میل سرور کو بہتر بنانے کی طرف بڑھیں۔ یہاں وہ اقدامات ہیں جو مدد کریں گے:

1. اس بات کو یقینی بنائیں کہ آپ کے ڈومین کے DNS ریکارڈز درست طریقے سے ترتیب دیئے گئے ہیں، بشمول SPF, ڈی کے آئی ایم، اور DMARC میل کی ترسیل کو بہتر بنانے اور سپیم سے بچانے کے لیے ریکارڈز۔ پیرامیٹرز کی صحیح ترتیب مضمون میں پایا جا سکتا ہے میل سرور کی تشخیص.
2. بلاکس سے بچنے اور میل کی ترسیل کو تیز کرنے کے لیے نیٹ ورک سیٹنگز کو چیک کریں، بشمول فائر وال کنفیگریشن اور روٹنگ کے اصول۔
3. سرور لوڈ کے مطابق پیغام کی قطار کے پیرامیٹرز کو ترتیب دیں۔ اس میں زیادہ سے زیادہ قطار کا سائز اور ٹائم آؤٹ سیٹ کرنا شامل ہو سکتا ہے۔
4. ان حلوں پر غور کریں جن پر ہم نے اس مضمون میں پہلے بات کی تھی۔ کارکردگی کو بہتر بنانے کے لیے وقتاً فوقتاً میل سرور ڈیٹا بیس کو بہتر بنائیں، ڈیٹا کی تلاش اور پروسیسنگ کو تیز کرنے کے لیے کیشنگ میکانزم کا استعمال کریں، جیسے DNS سوالات۔
5. اگر میل سرور کو اب بھی باقاعدگی سے زیادہ بوجھ کا سامنا کرنا پڑتا ہے، تو اسکیلنگ کے اختیارات پر غور کریں، جیسے میل سرورز یا کلاؤڈ سلوشنز کا کلسٹر استعمال کرنا۔

نتیجہ

سرور کا بڑھتا ہوا بوجھ براہ راست ویب سائٹ کی لوڈنگ کی رفتار کو متاثر کرتا ہے، بالآخر صارف کے تجربے اور سرچ انجنوں میں ساکھ کو متاثر کرتا ہے۔ اس طرح، اس بوجھ کا مؤثر طریقے سے انتظام وسائل کی مسلسل فعالیت کو یقینی بنانے اور زائرین کے لیے اس کی رسائی کو بڑھانے میں کلیدی کردار ادا کرتا ہے۔