Не скрою, программист я такой же как администратор. Но учиться никогда не поздно :)
Если приходит запрос а файла кэша нет, то скрипт создаёт временный файл со случайным именем и пишет в него результат работы (т.е. весь html файл), а в конце делается rename("временное_имя_файла","постоянное_имя_файла"). Не могу утверждать, но как мне кажется это достаточно надежный способ. Даже если будет одновременно несколько обращений к несуществующему кэшу, то проблем быть не должно - максимум это файл кэша несколько раз перезапишется.
Основная масса ответов по 21841 байт, но некоторые ответы в логах апача (с кодом 200) - 21840 или 21842. Почему - хороший вопрос. Буду думать. Но как это могло повлиять на мою проблему - пока не вижу связи.
Не может ли быть проблема быть связана с более низким уровнем? Например, со стеком tcp/ip? Там для меня пока совсем темный лес. Раньше где-то натыкался на интересные посты про оптимизацию серверов под большие нагрузки (правда под фряхой, а у меня debian) - так там какие-то изменения на уровне ядра предлагали делать. Сейчас правда ничего найти не могу :(
Попробую, только похоже по хорошему предварительно надо будет мне брать второй сервер, переносить туда сайт, а потом уже играться с этим.
Если файл "кэша" отсутствует, то php скрипт выполнится полностью и создаст этот файл. Если бы дело было в "кэше", то в server-status висели бы процессы соответствующих скриптов. Это бы нельзя было не заметить.
Начинаю сомневаться в вашей компетентности. Если внимательно посмотреть то что я написал, то там видно Document Length: 21841 bytes. Отличие на 1 байт - это 21840 или 21842.
25 тысяч онлайн по статистике liveinternet это не 25 тысяч запросов в секунду. Как я уже писал, server-status апача сообщал о примерно 100-110 запросах в секунду. Запуск ab с параметром -c 100 даёт (по server-status) порядка 1000 запросов в секунду (сюда же входят запросы реальных пользователей).
По манере общения сразу видно - профессионал.
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.
1. Да, выделенный. Core 2 Quad 8300, 4GB.
2. За каждого я не могу говорить, но проверялось с 3х компов (2 разных провайдера) и первое открытие сайта (любой страницы) - происходило медленно. По ощущениям - даже не открытие, а именно соединение. Все последующие запросы к сайту отрабатывались мгновенно. Если даже ничего не открывать в течении нескольких минут (я не засекал, но минут 10 проходило, а то и больше) - а потом снова открыть сайт, то он открывался мгновенно. Если подождать дольше - то снова первое соединение происходило медленно.
3,4. Не догадался проверить :( Сейчас-то уже поздно :) как трафик упал меньше 70-80 запросов к апачу в секунду - всё нормализовалось.
На проблемы с ДНС не было похоже. К сожалению не сохранил результаты проверки site-perf, там больше всего времени (по 5 секунд и больше) тратилось на "connect" (красная полоска), а с некоторых источников - вообще с первой попытки не соединяло, только со второй. причем если запускать повторно - то отрабатывало быстро.
Дак тут на форуме каждый второй пишет что он профессионал и "ацкий сотона". Как определить кто действительно умеет?
Аналогично ничего сказать не могу. Но почему такого не может быть, что действительно на первый взгляд (т.е. просмотрев стандартный набор параметров) - действительно ничего криминального не было видно? Ведь, теоретически, в медленном коннекте и провалах на хост-трекере мог быть виноват хостер? Это я уже позже выяснил, что у него проблем не было.
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. Возможно, что-то ещё по мелочи, что не должно оказывать существенного влияния на производительность.
ihc_ru
Скажите, пожалуйста, а как вы относитесь к ворованным сайтам? Обнаружил у вас старую копию своего сайта, которую похоже выкачали чем-то типа телепорта ещё год назад. Есть ли смысл обращаться с просьбой удалить этот сайт?
А что до сих пор оттуда не работает? У меня проблем нет. А вот вчера действительно было 2 небольших провала - с 11:24 по 11:36 и с 13:16 по 13:34. Второй я застал и увидел по хост-трекеру (ДЦ был не отовсюду доступен).
Тож не грузилось. Примерно с 13:30. Я тикет создать не успел - смотрю уже всё нормально заработало. Хост трекер подтверждает.
Скорее дело в Ростелекоме. У меня (собственно как и у всех остальных кто пользуется нашим мухосранским провайдером) аналогично до WebDC.ru по вечерам были потери по 30%. Написал в дата-центр и как мог расписал. Они поменяли маршруты и теперь всё стало ОК (огромное им ещё раз спасибо ;) ). Так что ещё раз пишите мастерхосту, прикладывайте trace, слёзно умоляйте поменять маршуты (если у них вообще есть такая возможность) и надейтесь на лучшее. Ну или пишите своему провайдеру гневные письма. Но провайдеры, как мне кажется - чаще игнорят. Не они ж посетителей теряют.
Если в ближайшее время не поднимутся - полрунета начнёт тормозить :)
