Плохая «Весна» или как причины задержек искали

[jrip]

Так и в чем мораль? не юзать bitrix?

[tkf]

а почему не юзать? в нем конечно полно своих проблем. Но это как и в любой другой CMS.
суть в том что проблемы могут подкрасться откуда не ждали, и иногда стоит довериться первым мыслям чем устраивать долгий и непонятный квест :)
Хотя в результате приходим к тому же. время только тратится.

[jrip]

Ну тогда странная мораль как бы.
Т.е. у нас есть мысли, мы им не доверям, потому что они первые, но иногда им нужно довериться.

[tattoor]

Это конечно увлекательно так искать проблемы, но если бы у вас стоял newrelic хватило бы одного взгляда.

[tkf]

Не знаю что у newrelic'а есть такая удобная интеграция с php. Надо будет попробовать как нибудь посмотреть на этого зверя. Спасибо.

[bat]

после обнаружения долгого session_start при хранении сессий в файлах, надо искать долгоиграющий параллельный запрос от того же пользователя, очевидно же

[tkf]

что интересно, хранение сессии в memcached проблему не решало. К тому же сыграло роль то что похожая проблема была относительно недавно на другом сервере, и там в итоге виноваты оказались винты, которые пришлось заменять. Вот мысль и ушла не в том направление :(

[jrip]

Так не важно же файлы или не файлы в этом случае.
И вообще по факту session_start тут только усугубляет проблему производительности и ни о чем не говорит.

[tkf]

именно уткнувшись в него, пошли по неверному пути, подменив причину следствием.

[inkvizitor68sl]

> Цепляемся с помощью strace.
Всегда делаю это сразу после того, как посмотрю в логи. Если нагрузка большая, то сначала смотрю в tcpdump на исходящие коннекты к 80/443, потом уже иду к владельцу проекта с просьбой положить всё это дело минут на 10, чтобы снять strace с тормозящих запросов.
Ни разу не подводило, хотя бы косвенно, но проблема всегда находилась сразу после прочтения одного трейса тормозящего запроса.

Чего и вам советую )

[tkf]

тут немного мешало то что было сложно поймать какой именно процесс обрабатывает тормозящий запрос. Потому что тормоза наблюдались в одном процессе. И strace тоже бы привел к ожиданию сессии, хотя другой процесс в этот момент и подвисал :(
Но да, strace надо было использовать раньше. Сэкономило бы время. Как я и написал в итоге.

[inkvizitor68sl]

Можно на пару минут запустить strace на все процессы апача, записать всё в один лог, потом по логу nginx найти тех, кто ушел с 499 (или 502 с 60 секунд в вашем случае, скорее всего, или 200-кой с адским временем ответа), потом грепом найти нужный трейс.

> тоже бы привел к ожиданию сессии
Ну там в 3-4 раза процесс медленнее начинает работать, до 60 секунд не дошло бы.

А ещё можно сразу писать с -r и искать те сисколлы, которые выполняются несколько секунд (в вашем случаем можно было бы сразу 50+ секунд искать), так даже быстрее (но это работает только в случаях, когда нужно найти сильные тормоза, на тормозах меньше секунды так сложнее искать).

[Nastradamus]

У меня был такой же сложный сайт на битриксе. Подобные проблемы, действительно, быстро решались с помощью XHProf (XHGui лучше сразу ставить).
Иначе, можно искать тормоза месяцами.

[TimsTims]

Спасибо за интересную статью!
Раскрылись глаза на такую казалось мелочь — session_start() и блокировки файлов сессий!

А я всё понять не мог, почему на нашем небольшом бэкэнде невозможно открытие на загрузку одновременно нескольких страниц, а выдавал только по одной… думал ограничения в браузере какое-то, или веб-сервер на одного клиента не дает больше процессов выполнять… а оказалось это просто блокировки файлов от session_start!

[jrip]

Тут стоить заметить, что это совсем не мелочь и, что в официальной доке по start_session про блокировки сказано, а вот в разных «учебниках» обычно нет.

[TimsTims]

Да что-то совсем про это ничего не сказанно: http://php.net/session_start

[jrip]

Грусть, однако, в переводе нет, а вам похоже по умолчанию как раз перевод отдается.

Я то специально вот сюда смотрел, тут есть, в блоке options:
php.net/en/session_start

[jrip]

Собственно, информация там о блокировка есть в базовом описании работы с сессиями, например вот тут даже в переводе:
php.net/manual/ru/session.examples.basic.php

Процитирую оттуда:

Замечание:
Сессии, использующие файлы (по умолчанию в PHP), блокируют файл сессии сразу при открытии сессии функцией session_start() или косвенно при указании session.auto_start. После блокировки, ни один другой скрипт не может получить доступ к этому же файлу сессии, пока он не будет закрыт или при завершении скрипта или при вызове функции session_write_close().
Скорее всего это станет проблемой для сайтов, которые активно используют AJAX и делают несколько одновременных запросов. Простейшим путем решить эту проблему будет вызов функции session_write_close() сразу же как только все требуемые изменения в сессии будут сделаны, предпочтительно ближе к началу работы скрипта. Также можно использовать другой механизм сессии, который поддерживает конкурентный доступ.

[nelson]

Блокировка сессии — это перебдение в 99% проектов.