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

radoslav68

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

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

тео

Well-Known Member
От: Проблем с процесорното време в ICN.bg

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

s1yf0x

Well-Known Member
От: Проблем с процесорното време в ICN.bg

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

radoslav68

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

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

s1yf0x

Well-Known Member
От: Проблем с процесорното време в ICN.bg

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

biks

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

Ъпгрейда е много вероятно да реши проблема.
 

AdSenser

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

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

radoslav68

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

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

s1yf0x

Well-Known Member
От: Проблем с процесорното време в ICN.bg

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

radoslav68

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

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

ggg007

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

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

r.stefanov

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

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

s1yf0x

Well-Known Member
От: Проблем с процесорното време в 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 и разходва ресурси, така че няма да помогне особенно.
 

sedo

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

r.stefanov

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

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

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

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

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

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

s1yf0x

Well-Known Member
От: Проблем с процесорното време в ICN.bg

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

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

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

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


Да тук трябва да призня, че nginx печели пред Apache. Снощи си чуках главата в стената с него.
 

NullByte

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

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

s1yf0x

Well-Known Member
От: Проблем с процесорното време в ICN.bg

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

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

r.stefanov

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

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

Достъп по IP адрес за автоматичният софтуер? IPN-а също.
 

Горе