Проблем с процесорното време в ICN.bg

radoslav68

radoslav68

Active Member
Здравейте колеги,

В рамките на няколко дена получавам два пъти от icn.bg имейли, че съм надвишил порцесорното време за този хостинг план, който ползвам. Разбира се аз не ги упреквам поне за сега. Сайта има 40-60 потребителя дневно и около 400 продукта. Всеки път, когато се правят някакви промени по продуктите или категориите от админ панела на сайта започва да дава грешки "error 28" или "internal server error 503", които след няколко минути се оправят.
Имам още 3 сайта хоствани при други компании и които са с Мадженто, но до сега никога не съм имал такива проблеми. Днес им писах, та ще видя какво ще стане или ще го местя сайта на друг ходтинг, ако не се оправи проблема.
 
От: Проблем с процесорното време в ICN.bg

Няма да те спази друг хостинг. Гадното е, че си налазен от нещо и трябва да го откриеш и спреш.
 
От: Проблем с процесорното време в ICN.bg

Споделения хостинг е възможно най-лошия избор за Magento, това го пише дори и във форумите им. Платформата е лакома, колкото и ресурси да и дадеш винаги ще ги разходи и ще пита за още. Въпреки, че съм фен на Magento никога не бих го ползвал за магазин с 400 продукта. Има далеч по-леки и пъргави платформи. Грешка 500 вероятно се получава при недостиг на памет или време за изпълнение на php процеса. Колко време цикли Magento-то преди да ти върне тази грешка?
 
От: Проблем с процесорното време в ICN.bg

s1yf0x каза:
Колко време цикли Magento-то преди да ти върне тази грешка?
Увеличете...
Около 10 сек. - по принцип има забавяне. От icn.bg ми отговориха на тикета, че началната страница много бавно зарежда - 0.71 сек., и се съмнявам, че може да е от скрипта на каросела, или от ajax плъгина за слойната навигация. Едва ли ще е от скрипта за cufon text.
 
От: Проблем с процесорното време в ICN.bg

Принципно при дефолтна инсталация прави доволно голям обем от mysql заявки за да зареди началната страница, а при допълнителни плъгини / модули още повече. Не знам какво да те посъветвам, аз поне не бих ползвал споделен хостинг за Magento или тази платформа за магазин с под 10к продукта.
 
От: Проблем с процесорното време в ICN.bg

Съгласен съм, че е така, ще трябва явно ъпгрейд на хостинг плана
 
От: Проблем с процесорното време в ICN.bg

Ъпгрейда е много вероятно да реши проблема.
 
От: Проблем с процесорното време в ICN.bg

Не знам как е при Мадженто, но в Уърдпрес успях да спестя много процесорно време, като си кеширах заглавната страница и sidebar-а с един прост скрипт:
http://forum.idg.bg/viewtopic.php?f=8&t=2630&start=0
Чрез него можеш да избереш на колко часа/минути да се обновява съдържанието на страницата или на конкретен кеширан елемент, вместо всеки потребител да генерира наново и наново едно и също нещо. Нямам идея обаче дали е приложимо в конкретния случай!
 
От: Проблем с процесорното време в ICN.bg

Компресирах цялото съдържание и направих някои промени в настройките за каталога и продуктите, обединих всички скриптове и css стилове. Оптимизирах някои неща за логовете - на 14 дни да изчиства кеша с cronjobs. Сега е много по-добре. Започнах да използвам и CloudFlare - имат го като опция в cPanel. Ако не се оправи ще преместя сайта на друг хостинг, защото тия си нямат никакво понятие от Мадженто явно.
 
От: Проблем с процесорното време в ICN.bg

gzip компресията, ще намали времето за зареждане на сайта, но ще вдигне разхода на процесорно време, имай го в предвид. При Magento забавянето идва не толкова от статичното съдържание, колкото от mysql заявките. cloudflare ще ти помогне ако имаш голямо количество снимки на продуктите. Не виждам причина за негативното ти отношение, тяхната работа е да разбират от cPanel и Linux, не от Magento :) .
 
От: Проблем с процесорното време в ICN.bg

s1yf0x каза:
gzip компресията, ще намали времето за зареждане на сайта, но ще вдигне разхода на процесорно време, имай го в предвид. При Magento забавянето идва не толкова от статичното съдържание, колкото от mysql заявките. cloudflare ще ти помогне ако имаш голямо количество снимки на продуктите. Не виждам причина за негативното ти отношение, тяхната работа е да разбират от cPanel и Linux, не от Magento :) .
Увеличете...
Благодаря, ще се съобразя за gzip компресията. Ядосвам се по-скоро на себе си и не искам да се приема, като опит да се насажда негативизъм. Верно е, че нямат в случая никаква вина.
 
От: Проблем с процесорното време в ICN.bg

Аз имах същият проблем с ICN. Писаха ми, че съм надвишил процесорното време. Имам сайт с wordpress при тях, и става въпрос за постоянни атаки на wordpress, които увеличават процеснорно време. Хост.бг много добре са го описали в блога си: http://blog.host.bg/2013/04/atakata-ot-12-04-izvodite-edna-sedmica-po-kasno/
Явно ICN не осъзнават причината за увеличеното процесорно време и ме накараха да си купя по скъп хостинг план, което и направих за съжаление. И все пак мисля, че icn.bg трябва да блокират тези атаки по някакъв начин и да не карат клиентите си с wordpress, да плащат за процесесорното време натрупано от недоброжелателни атаки.
 
От: Проблем с процесорното време в ICN.bg

fail2ban + iptables е много ефективен метод, ако не най-ефективният за блокиране на автоматичните атаки. Например при повече от два опита (или колкото му зададеш) за вход автоматично добавя ip адреса в iptables за определено време (или перманентно). Wordpress има и добавка http://wordpress.org/plugins/wp-fail2ban/ Трябва обаче да помолите хоста да конфигурират fail2ban на сървъра. Може да се настрои за всякакви други филтри, не само опит за login.
 
От: Проблем с процесорното време в ICN.bg

Лошото в случая е, че атаката идва от различни IP адреси и не се правят по 2 рекуеста от един и същ IP.

9-300 9353 0/0/1 W 0.04 182 0 0.0 0.00 0.00 89.34.213.178 ***************** POST /wp-login.php HTTP/1.0
9-300 9353 0/0/1 W 0.04 182 0 0.0 0.00 0.00 41.201.40.173 ***************** POST /wp-login.php HTTP/1.0
9-300 9353 0/10/11 W 0.17 151 0 0.0 0.01 0.02 90.61.21.52 ***************** POST /wp-login.php HTTP/1.0
9-300 9353 0/23/24 W 0.31 86 0 0.0 0.56 0.56 91.207.210.78 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/2/3 W 0.20 134 0 0.0 0.00 0.01 217.170.97.225 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/4/5 W 0.13 166 0 0.0 0.02 0.02 94.28.207.105 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/11/11 W 0.21 128 0 0.0 0.04 0.04 37.127.111.148 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/6/6 W 0.18 152 0 0.0 0.03 0.03 2.180.135.131 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/1/1 W 0.07 177 0 0.0 0.00 0.00 114.166.32.117 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/3/3 W 0.16 155 0 0.0 0.01 0.01 46.10.96.39 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/1/1 W 0.08 176 0 0.0 0.00 0.00 213.242.54.142 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/1/1 W 0.33 70 0 0.0 0.00 0.00 117.3.163.229 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/4/4 W 0.30 91 0 0.0 0.01 0.01 178.61.244.34 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/0/0 W 0.00 182 0 0.0 0.00 0.00 95.42.214.30 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/0/0 W 0.00 182 0 0.0 0.00 0.00 37.45.201.131 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/2/2 W 0.09 170 0 0.0 0.01 0.01 31.162.55.128 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/1/1 W 0.14 158 0 0.0 0.00 0.00 37.232.15.51 **************** POST /wp-login.php HTTP/1.0
9-300 9353 1/5/5 K 0.45 -2 1 0.8 0.01 0.01 85.118.193.224 **************** GET /menu.css HTTP/1.1
9-300 9353 0/0/0 W 0.00 182 0 0.0 0.00 0.00 95.111.73.254 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/3/3 W 0.22 123 0 0.0 0.01 0.01 83.149.21.3 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/1/1 W 0.21 128 0 0.0 0.00 0.00 50.194.128.89 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/6/6 W 0.43 8 0 0.0 0.01 0.01 78.99.38.55 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/0/0 W 0.00 182 0 0.0 0.00 0.00 2.60.89.47 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/1/1 W 0.06 181 0 0.0 0.26 0.26 212.102.29.137 **************** POST /wp-login.php HTTP/1.1
9-300 9353 0/14/14 W 0.38 25 0 0.0 0.30 0.30 91.216.66.120 **************** POST /wp-login.php HTTP/1.0
9-300 9353 0/5/5 W 0.17 155 0 0.0 0.01 0.01 188.169.239.213 **************** POST /wp-login.php HTTP/1.0
10-300 8728 0/8/8 W 0.25 195 0 0.0 0.02 0.02 109.96.43.158 **************** POST /wp-login.php HTTP/1.0
10-300 8728 0/4/4 W 0.45 86 0 0.0 0.01 0.01 178.93.68.191 **************** POST /wp-login.php HTTP/1.0
10-300 8728 0/2/2 W 0.39 129 0 0.0 0.01 0.01 187.10.110.127 **************** POST /wp-login.php HTTP/1.0
Увеличете...

Ето ти едни 30 реда от текущия статус на web server-а при подобна атаката. Дори и да се сложи допълнителен плъгин, той също използва php и разходва ресурси, така че няма да помогне особенно.
 
От: Проблем с процесорното време в ICN.bg

ggg007 каза:
Аз имах същият проблем с ICN. Писаха ми, че съм надвишил процесорното време. Имам сайт с wordpress при тях, и става въпрос за постоянни атаки на wordpress, които увеличават процеснорно време. Хост.бг много добре са го описали в блога си: http://blog.host.bg/2013/04/atakata-ot-12-04-izvodite-edna-sedmica-po-kasno/
Явно ICN не осъзнават причината за увеличеното процесорно време и ме накараха да си купя по скъп хостинг план, което и направих за съжаление. И все пак мисля, че icn.bg трябва да блокират тези атаки по някакъв начин и да не карат клиентите си с wordpress, да плащат за процесесорното време натрупано от недоброжелателни атаки.
Увеличете...

ICN е много хубава компания, качествени услуги, ама и мен ме изгониха по този начин. Надвишавал съм процесорното време. Пичове от ICN, вместо да гоните хората или да ги карате да плащат повече, просто нека някой от вашия екип да се грижи и да помага на хората да се разрешават проблемите. Не си мислете, че всеки има пари за програмист, който 24/7 да стои и да решава проблеми. Някои просто ползваме wordpress и знам, че товари... но това е. Вместо да ни гоните, помагайте ни, да решаваме проблемите, ако трябва да изключваме някои плъгини на wordpress.
 
От: Проблем с процесорното време в ICN.bg

s1yf0x каза:
Лошото в случая е, че атаката идва от различни IP адреси и не се правят по 2 рекуеста от един и същ IP.
Увеличете...

Да, така е. Аз по принцип го комбинирам с модула на nginx за лимит на рекуестите към дадена част от сайта. Броя айпита тук няма значение. Да речем 1 на 2 секунди или според нуждите. Все пак не всички биха искали такъв лимит.

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

Може да се направи още по-хитро и да закачиш и него към fail2ban или друго подобно решение.

Но и fail2ban ще намали доста натоварването.
 
От: Проблем с процесорното време в ICN.bg

r.stefanov каза:
Да, така е. Аз по принцип го комбинирам с модула на nginx за лимит на рекуестите към дадена част от сайта. Броя айпита тук няма значение. Да речем 1 на 2 секунди или според нуждите. Все пак не всички биха искали такъв лимит.

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

Може да се направи още по-хитро и да закачиш и него към fail2ban или друго подобно решение.

Но и fail2ban ще намали доста натоварването.
Увеличете...


Да тук трябва да призня, че nginx печели пред Apache. Снощи си чуках главата в стената с него.
 
От: Проблем с процесорното време в ICN.bg

Това с ботовете, дето зациклят wp-login от много IP адреси лесно се решава с един Auth на файла или директорията
или блокиране на всички ип-та с изключение на 2-3 които ползвате (специално за логина и административната част).
 
От: Проблем с процесорното време в ICN.bg

NullByte каза:
Това с ботовете, дето зациклят wp-login от много IP адреси лесно се решава с един Auth на файла или директорията
или блокиране на всички ип-та с изключение на 2-3 които ползвате (специално за логина и административната част).
Увеличете...

Не е толкова лесно. Има малка част от потребителите, които постват статии в блоговете си автоматично със софтуер, който не може да преодолее Auth с header 401 . А за Joomla видях и плъгин, който за на направи известие за плащане (IPN - instant payment notification) трябва да има достъп до административния панел. (o_O)
 
От: Проблем с процесорното време в ICN.bg

s1yf0x каза:
Не е толкова лесно. Има малка част от потребителите, които постват статии в блоговете си автоматично със софтуер, който не може да преодолее Auth с header 401 . А за Joomla видях и плъгин, който за на направи известие за плащане (IPN - instant payment notification) трябва да има достъп до административния панел. (o_O)
Увеличете...

Достъп по IP адрес за автоматичният софтуер? IPN-а също.
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе