- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Cab081, хорошо бы ввести такую функцию на хостинге, как ограничение на доступ для определенных ip, потому что половину нагрузки, похоже, создают поисковые роботы, которые не понимают Crawl-delay, в частности Aport
конечно, можно их запретить в .htaccess, но жалко: 1,5 перехода в день все-таки :)
А Вы могли бы сказать несколько слов о Вашем сайте? Например, движок и посещаемость уточните. Возможно у Вас проблема в отлюченном кешировании...
Очередная бяка от sweb.ru.
Прислали письмо, что большая нагрузка от моих сайтов - посещаемость там копеечная. Работает пара блогов на wordpress. Установлено кэширование.
Прислали данные о нагрузке в виде
Ниже приведена статистическая нагрузка аккаунта user_name.
+----------------------------------------------------------------------+
| server | user | cp_stat | quota | date | warnings | errors |
+----------------------------------------------------------------------+
| helium | user_name | 244.31 | 15 | 2009-04-15 | 5766 | 87 |
| helium | user_name | 237.47 | 15 | 2009-04-16 | 5600 | 55 |
| helium | user_name | 207.92 | 15 | 2009-04-17 | 5329 | 104 |
| helium | user_name | 243.73 | 15 | 2009-04-18 | 7509 | 207 |
| helium | user_name | 209.53 | 15 | 2009-04-19 | 6030 | 105 |
| helium | user_name | 240.29 | 15 | 2009-04-20 | 6011 | 157 |
| helium | user_name | 205.14 | 15 | 2009-04-21 | 4158 | 413 |
| helium | user_name | 185.5 | 16 | 2009-04-22 | 4556 | 72 |
| helium | user_name | 197.41 | 16 | 2009-04-23 | 4288 | 78 |
| helium | user_name | 167.76 | 16 | 2009-04-24 | 4666 | 55 |
+----------------------------------------------------------------------+
В таблице приведены следующие значения: cp_stat - статистическая процессорная
нагрузка аккаунта на сервер, warnings - число превышений нагрузки на процессор
более 10% (втечение 5 секунд), errors - число превышений нагрузки на процессор
более 50% (втечение 5 секунд). В первую очередь стоит обратить внимание на
параметр cp_stat (безразмерная величина, характеризующая статистическую нагрузку
на процессор втечение суток) - она не должна превышать заданных норм. Такими нормами
для виртуального хостинга (кроме тарифа VIP) является значение 50 и для тарифа VIP
значение - 90. Также необходимо обратить внимание на столбцы warnings и errors.
Число errors должно быть равно 0, а warnings должно стремиться к нулю. Нормально
отлаженные работающие скрипты среднего сайта не должны отнимать более 3% процессорного
времени более 3-5 секунд. Если это не так, и дальнейшая оптимизации невозможна,
следовательно необходимо рассмотреть вариант размещения проекта на выделенном сервере.
На мой запрос о более подробных данных о том, что именно - какие скрипты и запросы создают нагрузку предложили смотреть в логах время генерации страниц. Очень остроумно.
При этом подключен аккаунт на 25 доменных имен. Т.е. захостить у них даже 25 блогов wp не получится.
При этом фактически саппорт не заинтересован в решении проблемы, им решение видится только в виде VIP тарифа или VDS. VDS и будет, но только не в sweb.
Надеюсь, что кому-то это информация позволит не совершить ошибку при выборе хостинга.
По сути главная претензия от меня свебу - отказ в предоставлении конкретной статистике по нагрузке, которую они просто не хотят предоставить. Собрать ее и предоставить - вовсе не сложно. Или им нужно увольнять своих админов, если они не могут настроить элементарный лог для долгих запросов в ту же базу данных.
Значит, по порядку.
Очередная бяка от sweb.ru.
Прислали письмо, что большая нагрузка от моих сайтов - посещаемость там копеечная. Работает пара блогов на wordpress. Установлено кэширование.
Прислали данные о нагрузке в виде
Ниже приведена статистическая нагрузка аккаунта user_name.
+----------------------------------------------------------------------+
| server | user | cp_stat | quota | date | warnings | errors |
+----------------------------------------------------------------------+
| helium | user_name | 244.31 | 15 | 2009-04-15 | 5766 | 87 |
| helium | user_name | 237.47 | 15 | 2009-04-16 | 5600 | 55 |
| helium | user_name | 207.92 | 15 | 2009-04-17 | 5329 | 104 |
| helium | user_name | 243.73 | 15 | 2009-04-18 | 7509 | 207 |
| helium | user_name | 209.53 | 15 | 2009-04-19 | 6030 | 105 |
| helium | user_name | 240.29 | 15 | 2009-04-20 | 6011 | 157 |
| helium | user_name | 205.14 | 15 | 2009-04-21 | 4158 | 413 |
| helium | user_name | 185.5 | 16 | 2009-04-22 | 4556 | 72 |
| helium | user_name | 197.41 | 16 | 2009-04-23 | 4288 | 78 |
| helium | user_name | 167.76 | 16 | 2009-04-24 | 4666 | 55 |
+----------------------------------------------------------------------+
В таблице приведены следующие значения: cp_stat - статистическая процессорная
нагрузка аккаунта на сервер, warnings - число превышений нагрузки на процессор
более 10% (втечение 5 секунд), errors - число превышений нагрузки на процессор
более 50% (втечение 5 секунд). В первую очередь стоит обратить внимание на
параметр cp_stat (безразмерная величина, характеризующая статистическую нагрузку
на процессор втечение суток) - она не должна превышать заданных норм. Такими нормами
для виртуального хостинга (кроме тарифа VIP) является значение 50 и для тарифа VIP
значение - 90. Также необходимо обратить внимание на столбцы warnings и errors.
Число errors должно быть равно 0, а warnings должно стремиться к нулю. Нормально
отлаженные работающие скрипты среднего сайта не должны отнимать более 3% процессорного
времени более 3-5 секунд. Если это не так, и дальнейшая оптимизации невозможна,
следовательно необходимо рассмотреть вариант размещения проекта на выделенном сервере.
На мой запрос о более подробных данных о том, что именно - какие скрипты и запросы создают нагрузку предложили смотреть в логах время генерации страниц. Очень остроумно.
Эта информация доступна нашим пользователем. Объясню вкратце, где ее находить и как с ней работать самостоятельно.
Вам прислали статистику, в которой присутствуют поля warnings и errors. Эти поля, собственно, указывают на кол-во Ваших процессов за сутки, которые превысили допустимую норму.
Далее Вам должны были выслать детализированный лог по всем таким процессам, где указаны название процесса, использованный процент CPU и PID процесса. В наших access логах apache как и везде присутствует URL запроса и в этой же строке присутствует поле, указывающее PID этого процесса. Дополнительно в access логе также есть поле, указывающих время выполнения запроса в секундах (это 2 последних поля в строке access лога). На основании этих логов у Вас есть возможность отследить каждый запрос к вашему сайту, который вызвал превышение нагрузки, увидеть % cpu usage и время, которое потребовалось на выполнение запроса.
Признаю, это не достаточно наглядная форма отображения, мы подготовим инструментарий, который упростит этот момент. Но так или иначе всю необходимую детализацию Вам должны были предоставить.
При этом подключен аккаунт на 25 доменных имен. Т.е. захостить у них даже 25 блогов wp не получится.
Здесь замечу, что, вобщем-то, сайт сайту рознь. Есть блоги, которым и в одиночку на нашем VIP аккаунте будет тесно. Полагаю, Вы и сами это прекрасно знаете.
При этом фактически саппорт не заинтересован в решении проблемы, им решение видится только в виде VIP тарифа или VDS. VDS и будет, но только не в sweb.
Надеюсь, что кому-то это информация позволит не совершить ошибку при выборе хостинга.
По сути главная претензия от меня свебу - отказ в предоставлении конкретной статистике по нагрузке, которую они просто не хотят предоставить. Собрать ее и предоставить - вовсе не сложно. Или им нужно увольнять своих админов, если они не могут настроить элементарный лог для долгих запросов в ту же базу данных.
Претензия принята. Вся необходимая информация по превышениям нагрузки велась и ведется, и Вам должны были ее предоставить.
Я понимаю желание пользователя в случае проблемы растиражировать очередную бяку "любимого" хостера по форумам, но, согласитесь, конструктива в этом не очень много. Мы не закрываем глаза на собственные проблемы и всегда готовы принять замечания на промахи, которые допустили. Как говорится, помогите и вы нам помочь вам.
Я понимаю желание пользователя в случае проблемы растиражировать очередную бяку "любимого" хостера по форумам, но, согласитесь, конструктива в этом не очень много.
Конструктив очень простой - в техподдержке сидят "валенки", которые максимум что могут ответить - "подождите, админ придет в понедельник".
Вы - и есть тот самый админ? Так помогайте товарищам оперативнее ;)
в техподдержке сидят не валенки а суппортеры первого уровня. не секрет что в больших компаниях существует разделение по уровням техподдержки. первый уровень обороны - это суппорты которые могут ответить и помочь с простейшими проблема типа "почему мой сайт не открывается" и подобными. второй уровень - на проблемы посложнее и третий уровень - это например для случаев превышения нагрузки. Не совсем понятно почему кидаются предъявы (именно так это выглядит по стилю поста) на широкораспространненую и логичную практику решения вопросов. Называть же "валенками" людей потому что некоему клиенту захотелось мгновенно получить ответ на вопрос ответ на который НЕ ВХОДИТ в их ДОЛЖНОСТНЫЕ ОБЯЗАННОСТИ как минимум неэтично.
Я торчу от наших провайдеров, ой ребята провайдеры! Кризис закончится и пойдете вы на завод с таким подходом к рынку ваших услуг.
Очень распространенная причина резкого роста нагрузки заключается в следующем. На сайте были скрипты с правами 777, благодаря которым сайт был заражен вирусом. Вирус размещает на сайте перловский скрипт, который начинает активно спамить в результате резко возрасатет нагрузка на процессор.
Не нужно отрицательно высказываться в отношении хостера. Если человек платит 3 доллара в месяц и при этом постоянно садит весь сервер, отношение к такому пользователю будет соответствующим, пожалуйте на виртуальный сервер, чтобы не мешать другим пользователям, либо освободите хостинг.
Это не мой случай.
Причем до анонса sweb виртуальных серверов таких писем не было.
При грамотной настройке сервера это сделать проблематично. Цена кстати 10 долларов :). Была.
Все "мегатяжелые" сайты я уже перенес и они прекрасно себя чувствуют на дешевом VDS за 250 рублей, но уже не у sweb. Т.е. VDS с ОЗУ 96 Мб и CPU 400 МГц может это потянуть, а сервер sweb - нет. Разница в конфиге у VDS и сервера для шаред хостинга - колоссальная. Я думаю все понимают, что на начальном тарифе с VDS сайту жить намного сложнее чем не полноценном сервере. Но ведь живет и не падает и на нагрузку мне не указывают, и проц не зашкаливает. И измеряется это не в неизвестных попугаях.
Главная претензия именно в том, что не предоставили нормальных инструментов и отчетов по нагрузке. Если я не устраиваю как клиент - это бизнес и пофиг сколько лет я приносил компании деньги, нам стало не по пути. Но уж или сказали бы прямо об этом, или оказали бы помощь в уменьшении нагрузки. Кстати мастерхост тоже ко мне выдвигал претензии года полтора назад, на мой вопрос мне дали полную информацию о том, что именно создает нагрузку и проблему мы совместными усилиями решили, так как на шареде возможности по мониторингу мягко говоря ограничены.
Что за "админ", который просит меня уменьшить нагрузку и при этом говорит, что он не может дать мне список запросов, которые выполняются в базе данных дольше всех?
Я не устраиваю грязевые ванные, никого не пиарю, мне за это не платят :). Я хочу предупредить других людей. А так каждый для себя сам сделает вывод. Если у кого-то микросайт он наверное не столкнется с этими проблемами, если к нему ходит хотя бы 500 человек в день - будь готов, как говорили в моем детстве... Я для себя понял, что даже скромные 25 сателлитов sweb не потянет. Так как мне даже не удалось добавить к ним столько доменов проблемы начались раньше.
очередная провокация.