- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вот порылся на форуме и не нашел такой актуальной темы, как тестирование производительности сайта и вылавливание битых скриптов, которые могут загрузить и перегрузить систему (типа DoS :confused: ), а соответсвенно и стать причиной проблем с хостером. Хотя последствия этой темы постоянно тут обсуждаются - и люди спрашивали, что делать, считаю, что главное предвидеть такую возможность и к ней подготовиться.
Т.к. действенного способа тестирования я так и не нашел, то решил немного поэксперементировать. Итак:
Задание: съэмулировать максимально-возможное количество запросов средствами, которые по своей функциональности напоминают пауком (crawlers :) ) и которые доступны народу. При этом провести мониторинг системы и прочее. Для мониторинга было написано письмо хостеру - чтобы мона было получить статистику. Для монитора БД использовался PHPMyAdmin - раздел - показать процессы (а проще SHOW PROCESSLIST)
Средства: PagePromoter 6.4 (другой нет) тама при регистрации ресурса есть пункт, который позволяет обходить сайт в режиме паука (так и написано Spidering) и собирать все внутренние и внешние ссылки. Кстати собирает он с большей скоростью, чем пауки, которые конечно не криво написаны ;)
Итак итоги: запуск PagePromoter 6.4 на вытаскивание ссылок с указанием максимальной вложенности и паралельный просмотр в броузере и отдельно в PHPMyAdmin показали, что в моем случае (а это порядка 600 внутренних ссылок) при просмотре морды сайта идет сообщение, о том, что невозможно соединиться с базой данных. При изучении PHPMyAdmin - то, что остается около 20 процессов в состоянии sleep (ожидание продолжения передачи данных или закрытия соединения), которые к моему ужасу закрываться не собирались. Вообщем, что и требовалось доказать - что сам где-то что-то не так записал.
Решение: посмотрел код, воспользовался функцией mysql_close() для закрытия всех обращений к базе данных. Результат - :idea: - снижение нагрузки и уменьшение процессов mysql до 2-х. Основного (родительского) и дочернего (остальные все начали вовремя закрываться). Информацией от хостера пока поделиться не могу - вроде во вторник пришлют - но тока думаю ничего лестного тама в мой адрес я не услышу :) Думаю - там тоже не все так гладко :( Эххх... (еще работать и работать)
Вот так вот тест получился - надеюсь будет всем полезно, если у кого-то был подобный опыт прошу поделиться - очень интерестно :idea: