Cron jadvaliga * * * * * yozish juda oson: vazifa har daqiqada ishga tushadi va siz natijani deyarli darhol olasiz. Ammo bu oddiy qator kuniga 1440 marta, oyiga esa qirq mingdan ortiq marta yangi jarayon ochadi. Agar har bir ishga tushish yarim soniyada tugaydigan yengil tekshiruv bo'lsa, zarar sezilmaydi. Lekin ko'pincha bu yerda butun sayt freymvorki yuklanadi, bazaga ulanish ochiladi va ish bo'lmasa ham resurs sarflanadi. Shu maqolada har daqiqalik cron serverga aynan nima qilishini va undan qanday oqilona foydalanishni ko'rib chiqamiz.
Har bir ishga tushish nimaga tushadi
Cron PHP skriptini chaqirganda server yangi PHP jarayonini yaratadi, interpretatorni yuklaydi, skript kodini o'qiydi va kompilyatsiya qiladi. WordPress yoki Laravel kabi tizimda buning ustiga butun yadro, plaginlar va sozlamalar yuklanadi, ko'pincha bazaga bir nechta so'rov yuboriladi. Bu ishlarning hammasi "bajariladigan vazifa bormi?" degan savolga javob berish uchun qilinadi, javob esa aksariyat hollarda "yo'q" bo'ladi. Ya'ni protsessor vaqti va xotira foydali ish uchun emas, balki doimiy tayyorgarlik uchun sarflanadi.
Shared hostingda bitta serverda yuzlab saytlar ishlaydi. Har bir mijoz o'zining bir-ikkita har daqiqalik vazifasini qo'shsa, daqiqa boshida bir vaqtning o'zida ko'plab jarayonlar uyg'onadi. Bu yuklama cho'qqisi barcha saytlarning javob tezligiga ta'sir qiladi, shu jumladan sizning saytingizga ham. Shu sababli ko'p hosting tariflarida protsessor va jarayonlar soniga chegara qo'yiladi va tez-tez ishlaydigan og'ir cron aynan shu chegaraga birinchi bo'lib uriladi.
Ustma-ust tushish: eng xavfli holat
Muammo ayniqsa skript bir daqiqadan uzoqroq ishlaganda kuchayadi. Faraz qilaylik, tashqi API sekin javob beryapti va skript 3 daqiqa kutib qoldi. Shu vaqt ichida cron yana ikki nusxani ishga tushiradi, ular ham kutib qoladi, keyin yana. Bir necha daqiqada o'nlab bir xil jarayon xotirani to'ldiradi, bazada ulanishlar soni chegaraga yetadi va sayt "Database Error" bera boshlaydi. Bunday zanjirli qulash ko'pincha tunda, hech kim kuzatmayotgan paytda yuz beradi.
Buning oldini olishning eng oddiy usuli — flock bilan qulf qo'yish. U oldingi nusxa tugamaguncha yangisini ishga tushirmaydi va shunchaki o'tkazib yuboradi:
* * * * * /usr/bin/flock -n /tmp/navbat.lock /usr/bin/php /var/www/user/data/www/misol.uz/cron/navbat.php >> /var/www/user/data/logs/navbat.log 2>&1
wget yoki curl orqali o'z saytingizni chaqirish
Ba'zi qo'llanmalar cron'da wget -q -O - https://misol.uz/cron.php kabi buyruq yozishni maslahat beradi. Bu holatda vazifa veb-server orqali o'tadi: u PHP-FPM ishchilaridan birini band qiladi, so'rov tashrif buyuruvchilar bilan bir navbatda turadi va vaqt chegarasiga ham bo'ysunadi. Har daqiqada shunday chaqirish haqiqiy foydalanuvchilar uchun mo'ljallangan ishchilarni egallaydi. Iloji bo'lsa skriptni to'g'ridan-to'g'ri PHP CLI orqali ishga tushiring, chunki u veb navbatga ta'sir qilmaydi va uzoq ishlar uchun qulayroq.
Qaysi vazifalarga haqiqatan har daqiqa kerak
Har daqiqalik chastota faqat kechikish sezilarli zarar keltiradigan joyda o'zini oqlaydi: to'lov holatini tekshirish, SMS navbatini jo'natish yoki tasdiqlash kodlarini yuborish. Valyuta kursini yangilash, sitemap yaratish, eski sessiyalarni tozalash yoki statistika yig'ish uchun har 15-30 daqiqa, hatto kuniga bir marta ham yetarli. Har bir vazifa uchun "bu natija 10 daqiqa kechiksa nima bo'ladi?" degan savolni bering. Agar javob "hech narsa" bo'lsa, chastotani kamaytiring.
| Vazifa | Oqilona chastota | Cron ifodasi |
|---|---|---|
| To'lov holatini tekshirish | har 1-2 daqiqa | */2 * * * * |
| Valyuta kursini yangilash | har 30 daqiqa | */30 * * * * |
| Sitemap yaratish | kuniga 1 marta | 15 4 * * * |
| Eski fayllarni tozalash | haftasiga 1 marta | 30 3 * * 0 |
Yana bir foydali odat — vazifalarni soat boshiga emas, tasodifiy daqiqaga qo'yish. Ko'pchilik 0 * * * * yozgani uchun har soat boshida server yuklamasi keskin oshadi. 17 * * * * kabi yozuv o'sha cho'qqidan qochishga yordam beradi.
Yengil tekshiruv, og'ir ish faqat kerak bo'lganda
Agar vazifa haqiqatan tez-tez tekshirilishi kerak bo'lsa, skriptning boshini iloji boricha yengil qiling. Avval arzon tekshiruv bajarilsin — masalan, navbat faylining mavjudligi yoki bazadagi bitta oddiy so'rov — va faqat ish bor bo'lsa freymvork yuklansin. Bunda ishga tushishlarning aksariyati bir lahzada tugaydi.
<?php
// cron/navbat.php
if (!file_exists(__DIR__ . '/../data/navbat.flag')) {
exit; // ish yo'q, freymvork yuklanmaydi
}
require __DIR__ . '/../bootstrap.php';
// ... navbatni qayta ishlash ...
unlink(__DIR__ . '/../data/navbat.flag');
Og'ir, lekin shoshilinch bo'lmagan ishlarni esa past ustuvorlik bilan ishga tushirish mumkin. nice va ionice buyruqlari jarayonga protsessor va disk navbatida kamroq ulush beradi, shunda sayt tashrif buyuruvchilari sekinlashuvni sezmaydi:
15 4 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c3 /usr/bin/php /var/www/user/data/www/misol.uz/cron/sitemap.php >> /var/www/user/data/logs/sitemap.log 2>&1
Amaliy misol: klinika sayti
Toshkentdagi xususiy klinika saytida bemorlarga qabul eslatmasini yuboruvchi skript har daqiqada ishlardi. Har safar u butun CMS'ni yuklab, ertangi kunning barcha yozuvlarini bazadan tortib olardi, garchi eslatmalar kuniga atigi bir necha o'nlab bo'lsa ham. Ertalabki tashriflar paytida sayt sekinlashdi, hosting panelida esa protsessor chegarasi ogohlantirishlari paydo bo'ldi. Skript har 10 daqiqada ishlaydigan qilib o'zgartirildi, unga flock qo'shildi va so'rov faqat hali eslatma yuborilmagan yozuvlarni oladigan qilindi. Bemorlar eslatmani avvalgidek o'z vaqtida olishda davom etdi, sayt esa ertalab ham tez ishlay boshladi.
Yuklamani o'zingiz o'lchab ko'ring
Bir ishga tushish qancha vaqt va xotira olishini bilish uchun skriptni terminalda /usr/bin/time -v bilan ishga tushiring. Natijada "Elapsed (wall clock) time" va "Maximum resident set size" qatorlari ko'rinadi. Bu raqamni kuniga necha marta ishga tushishiga ko'paytirsangiz, vazifa umumiy qancha resurs olishi aniq bo'ladi.
/usr/bin/time -v /usr/bin/php /var/www/user/data/www/misol.uz/cron/navbat.php
sayt.uz hostingida cron vazifalarining ro'yxati va jadvali ISPmanager panelida ko'rinadi, panelga esa sayt.uz kabinetidan kirasiz. Agar saytingiz sekinlashib, sababi cron'dami yoki yo'qmi aniq bo'lmasa, texnik yordamga murojaat qiling — server tomonida qaysi jarayonlar ko'p resurs olayotganini ko'rish mumkin.