zeribaveg сделайте как я предложил. Это даст вам понимание, связан ли более долгий ответ сервера с бизнес логикой приложения, или с чем-то другим (например более долгий dns lookup, задумчивый прокси, сайты на медленном диске и пр.).
Если проблема не в приложении, оптимизировать бд бесполезно.
Если проблема в приложении, следует выявить сначала узкие места (не факт что проблема именно в бд).
zeribaveg
Вы говорите что сайты одинаковые, но потом пишите что у них разный размер бд. Если хотите протестить одинаковые сайты, поставьте на всех простейших скрипт (без wordpress'a и пр.) и посмотрите время ответа.
Владимир Ревякин, смотрите: в режиме dynamic fpm будет рестартить процесс после обслуживания определенного числа запросов (директива pm.max_requests в конфиге fpm pool);
в режиме ondemand будет генерить процессы "по требованию" и рестартить незанятые процессы (idle child) по таймауту или по достижению max_requests.
Судя по логу прежде чем произошла ошибка процесс работал 26412/(60^2)=7.33 часов - это много. Ваш pm.max_requests установлен в слишком больше значение для режима dynamic. Попробуйте снизить его так, чтобы был рестарт хотя бы раз в 15 минут. Если у вас все логи об ошибке упираются в какой-нибудь memory leak (child'ы работают часы прежде чем отдать sigbus), это решит проблему.
Если проблема не решится: надо понять, с чем связана ошибка: с логикой ваших скриптов или с чем-то другим. Если с логикой скриптов - правите логику скриптов. Если с чем-то другим - это может быть какое-нибудь дополнение php (apc часто грешит проблемами с памятью), конфиги (хотя вы сказали что все настроено), ограничения коннекта на связке веб-сервер - php-fpm (если у вас связь через файловый unix сокет, попробуйте сделать через сетевой, т.е. tcp 9000 порт), или какая-нибудь мгновенная утечка (сделайте free -m и htop и посмотрите, сколько у вас свободной RAM).
>>видел я это, там просто обычная Model и все, а мне надо AR завернуть в Model, лучше найдите мануал об этом.
Там почти все есть. Есть форма загрузки (UploadForm). У нее есть свойство - $imageFile. Есть метод загрузки формы (upload). Вы могли бы:
1.1 в класс формы добавить новое свойство $myModel (или другое название: то чем является ваша модель к чему файл крепите)
1.2 в метод upload добавить логику по валидации и сохранению $myModel
1.3 в контроллере загружать данные в форму и вызывать ее метод загрузки
Коль метод загрузки upload начнет отвечать не просто за загрузку файла, а за ряд действий по обработке формы, можно переименовать его в "сохранить" (save), "обработать" (process) или "отправить" (submit).
>>Найти бы их нормальные.
Для простых решений обычно делают свое, для сложных - ищут готовое. Для данной задачи пожалуй лучше написать свое.
Святослав Белимов лучше DateTime, формат unix time платформозависим, на 32 битной архитектуре корректо работает только в диапазоне [1970-01-01, 2038-01-19]
Да кстати есть позиции разрабов которые открыты чуть ли не круглый год - помониторьте работные сайты. Для соискателя шансы устроиться туда минимальны, можно сходить только за "поболтать".
Если вы имеете в виду Selenium Webdriver, то он легко интегрируется в Сodeception на уровне приемочных (user acceptance) тестов. codeception.com/docs/03-AcceptanceTests см. Selenium
Запускать юнит, функциональные и приемочные тесты можно как вместе, так и под отдельности.
>>а так как в доках пишут про менеджера пишущего фитчу ... ну и что он там напишет? "кликаю сюда вижу сообщение success" ? а то что у меня за этой кнопкой 10 итераций он даже и не знает
Да Behat просто нацелен на команды которые активно пишут спеки, где либо манагер с техбекграундом, либо есть отдельные QA команда/спец, которые как правило не знают php. Если все тесты пишут php разработчики, на мой взгляд Codeception уместнее.
Рестартаните сервисы (php, апач), попытайтесь запустить простейший скрипт (echo 'test'; exit;) - мб ваше приложение в новом окружении стучится куда-то и не может получить доступ.
Если не получится, значит надо копать в сторону конфигов:
1. Таймаут апача должен быть не меньше таймаута у cgi php (60 секунд обычно).
2. Отключить access логи.
3. Посмотреть через какой-нибудь ps aux | grep php какие есть процессы, может что-то в фоне блочит выполнение php. Посмотреть скорость записи/чтения с дисков.
