- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Возникла вчера непонятная для меня проблема при огромном числе посетителей. При первом открытии сайта страница грузилась очень долго (точнее долго не соединялось). То что видел я лично - от 5 до 15 секунд. Проверка по хост-трекеру давала от 3 до 10 таймаутов соединения (в т.ч. несколько Unknown reason). После того как соединение установилось - страница открывались мгновенно, все последующие страницы - тоже. Можно было бы предположить, что в этом случае помогал keep_alive, но он установлен всего на 15 секунд, в то время как страницы нормально открывались и через несколько минут простоя. Сначала сам проверил все логи и никаких ошибок не нашёл, затем попросил сотрудника из systemintegra посмотреть (хвала им за то, что в новогоднюю ночь работают и цены не меняют!) - Антон также подтвердил что никаких ошибок на сервере нет. Ресурсы - в избытке. Всё время top выглядел примерно следующим образом:
top - 20:24:40 up 1 day, 17:31, 1 user, load average: 0.37, 0.40, 0.43
Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.3%us, 2.1%sy, 0.0%ni, 90.7%id, 0.2%wa, 0.0%hi, 0.7%si, 0.0%st
Mem: 4055312k total, 1884468k used, 2170844k free, 51952k buffers
Swap: 2104508k total, 0k used, 2104508k free, 1321688k cached
Канал загружен был от силы на 50%. Постоянное обновление server-status апача показывало, что одновременно работает максимум 2-3 соединения. Количество запросов в секунду >100 (статику раздаёт nginx). Т.е. вроде бы и апач не был перегружен. Начал было грешить на проблемы хостера/дата-центра, но можно сказать чудом в новогоднюю ночь удалось пообщаться с руководством дата-центра и мне сказали что проблем нет. Получается что проблема была именно в моём сервере. А дальше чисто случайно обнаружил такую вещь - если рестартануть апач или nginx, то сайт какое-то время сразу открывался мгновенно и ошибок по хост-трекеру вообще не было. Спустя какое-то время всё становлось как было - и частичная недоступность по хост-трекеру, и медленное первое открытие. Когда трафик немного спал - проблема исчезла сама собой.
Такое ощущение, что где-то какая-то очередь забивалась и из-за этого были такие проблемы. Может быть кто-то сможет подсказать в каком направлении стоит "копать"?
Спасибо.
Может быть кто-то сможет подсказать в каком направлении стоит "копать"?
Доверять решение проблем тем, кто это умеет. Покуда не стало поздно. Может теперь вы поняли почему люди покупают услуги администрирования, в то время как "все работает"...
Ничего плохого не хочу сказать про systemintegra - но имея явно максимум информации (были на месте) - они не узнали абсолютно ничего существенного. Боюсь, без существенно более полной информации от вас (тот же вывод mod_status на момент проблемы, top, mysql processlist, статистика munin, настройки _всех_ замешанных сервисов от nginx до апача/sql, и т.п. и т.д.) - угадайки от местных телепатов будут еще менее полезны.
Доверять решение проблем тем, кто это умеет.
Дак тут на форуме каждый второй пишет что он профессионал и "ацкий сотона". Как определить кто действительно умеет?
Аналогично ничего сказать не могу. Но почему такого не может быть, что действительно на первый взгляд (т.е. просмотрев стандартный набор параметров) - действительно ничего криминального не было видно? Ведь, теоретически, в медленном коннекте и провалах на хост-трекере мог быть виноват хостер? Это я уже позже выяснил, что у него проблем не было.
mod_status - описывал в первом посте: ничего особенного там не было. висит 10 свободных процессов (maxclients стоит 150), из них при постоянном обновлении - занято было 2-3, а то и вообще один.
top - прикладывал выше, на протяжении нескольких часов особых изменений также не было.
mysql - фактически не использовался. Сайт самописный - ещё до роста нагрузки я включил своё собственное "кэширование" (страница один раз генерируется и валяется обычным файлом на tmpfs диске. php скрипт проверяет есть ли файл, если есть - считывает его и отдаёт. Запросы к БД отсутствуют).
munin - каюсь, отсутствует. надо будет поставить.
настройки всех сервисов - в целом стандартные для debian 5 + ispmanager lite.
За исключением увеличенных worker_processes до 4, worker_connections 4000 и worker_rlimit_nofile 16000, keep_alive 15 для nginx. Возможно, что-то ещё по мелочи, что не должно оказывать существенного влияния на производительность.
Согласен с myhand - надо смотреть.
Дак тут на форуме каждый второй пишет что он профессионал и "ацкий сотона". Как определить кто действительно умеет?
TC - myhand не кричит, что он Адский СоТоНа ;)
myhand - мне вот что понравилось ;)
Антон также подтвердил что никаких ошибок на сервере нет.
В то время как сайты тупят, сотрудник из systemintegra - говoрит нету ошибок ;) новогодняя сказка ;)
1. У вас выделенный сервер или VPS?
2. Первая страница долго грузится у каждого нового посетителя или только у первых посетителей?
3. Попробуйте зайти сразу на бэкенд http://site.ru:8080/ Проблема в этом случае остается?
4. Попробуйте зайти сразу на бэкенд по IP http://11.22.33.44:8080/ (сайт сделайте сайтом по умолчанию) Проблема в этом случае остается?
1. У вас выделенный сервер или VPS?
2. Первая страница долго грузится у каждого нового посетителя или только у первых посетителей?
3. Попробуйте зайти сразу на бэкенд http://site.ru:8080/ Проблема в этом случае остается?
4. Попробуйте зайти сразу на бэкенд по IP http://11.22.33.44:8080/ Проблема в этом случае остается?
1. Да, выделенный. Core 2 Quad 8300, 4GB.
2. За каждого я не могу говорить, но проверялось с 3х компов (2 разных провайдера) и первое открытие сайта (любой страницы) - происходило медленно. По ощущениям - даже не открытие, а именно соединение. Все последующие запросы к сайту отрабатывались мгновенно. Если даже ничего не открывать в течении нескольких минут (я не засекал, но минут 10 проходило, а то и больше) - а потом снова открыть сайт, то он открывался мгновенно. Если подождать дольше - то снова первое соединение происходило медленно.
3,4. Не догадался проверить :( Сейчас-то уже поздно :) как трафик упал меньше 70-80 запросов к апачу в секунду - всё нормализовалось.
На проблемы с ДНС не было похоже. К сожалению не сохранил результаты проверки site-perf, там больше всего времени (по 5 секунд и больше) тратилось на "connect" (красная полоска), а с некоторых источников - вообще с первой попытки не соединяло, только со второй. причем если запускать повторно - то отрабатывало быстро.
Аналогично ничего сказать не могу. Но почему такого не может быть, что действительно на первый взгляд (т.е. просмотрев стандартный набор параметров) - действительно ничего криминального не было видно?
Вы поставили задачу "определи мне причину такой-то проблемы" или "посмотри что криминального"?
Как определить кто действительно умеет?
Например, не берется за задачу, если не может ее выполнить или она глупа.
Сайт самописный - ещё до роста нагрузки я включил своё собственное "кэширование" (страница один раз генерируется и валяется обычным файлом на tmpfs диске. php скрипт проверяет есть ли файл, если есть - считывает его и отдаёт. Запросы к БД отсутствуют).
Может и в этом дело.
Возможно, что-то ещё по мелочи, что не должно оказывать существенного влияния на производительность.
Дъявол в мелочах. Не хотите предоставлять информацию - продолжайте надеяться на телепатов.
1. У вас выделенный сервер или VPS?
Тебе не видно?
По ощущениям - даже не открытие, а именно соединение.
Может ДНС. Проблема повторялась, если попытаться через несколько минут с того же клиента? Либо тот самый "кеш".
3,4. Не догадался проверить :( Сейчас-то уже поздно :)
Чудо, man ab осилишь самостоятельно?
homer18, у нас была похожая ситуация на похожей конфигурации сервера, кроме одного момента - LA взлетал до 25.0 - 30.0 и держался до 10 минут. Оказалось что, самописные движки сыпали всякий хлам в error.log и ежедневная ротация логов (00:00 по МСК) совпадала со временем пикового посещения посетителей (22.00 по Украине). Ребята из systemintegra заметили и подправили ротацию.
А вообще Вам надо приглашать админа чтобы наблюдал. На форуме, в слепую, Вы диагноз не узнаете ...
homer18, у нас была похожая ситуация на похожей конфигурации сервера, кроме одного момента - LA взлетал до 25.0 - 30.0 и держался до 10 минут. Оказалось что, самописные движки сыпали всякий хлам в error.log и ежедневная ротация логов (00:00 по МСК) совпадала со временем пикового посещения посетителей (22.00 по Украине). Ребята из systemintegra заметили и подправили ротацию.
А вообще Вам надо приглашать админа чтобы наблюдал. На форуме, в слепую, Вы диагноз не узнаете ...
Что-бы вы знали, на будущее, у вас разные ситуации ( земля и небо )
Что-бы вы знали, на будущее, у вас разные ситуации ( земля и небо )
Одинаковые. "Все итак работает, а если я замечу проблему - придет валшебник и исправит за 5 минут и 5$" (тм)
Чудо, man ab осилишь самостоятельно?
По манере общения сразу видно - профессионал.
Document Path: /
Document Length: 21841 bytes
Concurrency Level: 100
Time taken for tests: 1.838 seconds
Complete requests: 2000
Failed requests: 368
(Connect: 0, Receive: 0, Length: 368, Exceptions: 0)
Write errors: 0
Total transferred: 43995608 bytes
HTML transferred: 43681608 bytes
Requests per second: 1087.86 [#/sec] (mean)
Time per request: 91.923 [ms] (mean)
Time per request: 0.919 [ms] (mean, across all concurrent requests)
Transfer rate: 23369.75 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.1 0 6
Processing: 5 89 11.3 91 108
Waiting: 3 89 11.4 91 108
Total: 8 90 10.6 91 108
Percentage of the requests served within a certain time (ms)
50% 91
66% 93
75% 94
80% 94
90% 96
95% 98
98% 100
99% 102
100% 108 (longest request)
Посмотрел в логах почему 368 Failed - там размер у них на 1 байт отличается.
P.S. Сервер сейчас под нагрузкой. По статистике LiveInternet >5000 online. Проблемы были вчера когда онлайн было >25000.