А глупо делать регулировангие timeout. Вы просто будете часто получать состояние что воркеры ждут, пока OCI ответит. А клиенты будут сидеть в backlog и видеть waiting site.com в своих браузерах.
Увы, но вы не дали ответы. И даже не обозначили вопросы (не сказали про самую важную проблему). Вы просто сделали не верные выводы не до конца поняв их причину. Увы.
Расковырять OCI не получится, Oracle не раскрывает исходники. Если альтернативных вариантов не будет, то «допилить» попробуем nginx, благо код очень осмысленный и отлично читается. За наводку на epoll_wait спасибо!
С этим понятно, но мне не понятно как вы хотите и что пилить? Внести точку синхронизации из nginx в OCI? Возможно, но OCI закрыт.
Помойму вы не понимаете что вы хотите сделать, честно.
Обычно люди берут данные и считают дисперсию случайной величины, и на основание этого дают проценты. А так, это голые «вумные» слова, которые только повышают энтропию. Увы.
Далее, а сколько у вас было worker процессов у fastcgi сервера? А если их сделать штук 100? А если написать на тредах?
Сейчас вы имеете, фактически, демонстрацию понятной проблемы — в асинхронном сервере (nginx/fastcgi) кто-то заблокировался. То, что overhead на блокировку если внести ее в nginx меньше, понятно. Только в чем тут фикус, новшество и зачем вообще, кроме письку показать, стоило писать сей текст?
Делать так в контексте высокой нагрузки нельзя. А зачем так извращаться в других случая — я не понимаю.
вам придется расковыривать OCI и переносить из нее точку синхроноизации в epoll_wait в nginx. Да, я верю что это возможно, но есть подозрение что придется этот OCI переделать.
И плохо что вы не написали что это только прототип. И в жизни это использовать нельзя.
Но не это меня привлекает в программирование. Не результат.
А я сейчас уже перешел грань, когда ты стараешься объяснить себе, что это не баг, и не ошибка, это космические лучи делают биты ломают… Старость?
if (!-e $request_filename) { rewrite ^.*$ /index.php last; }Очень плохо. Идите читайте про
try_files.С этим понятно, но мне не понятно как вы хотите и что пилить? Внести точку синхронизации из nginx в OCI? Возможно, но OCI закрыт.
Помойму вы не понимаете что вы хотите сделать, честно.
Сейчас вы имеете, фактически, демонстрацию понятной проблемы — в асинхронном сервере (nginx/fastcgi) кто-то заблокировался. То, что overhead на блокировку если внести ее в nginx меньше, понятно. Только в чем тут фикус, новшество и зачем вообще, кроме письку показать, стоило писать сей текст?
Делать так в контексте высокой нагрузки нельзя. А зачем так извращаться в других случая — я не понимаю.
вам придется расковыривать OCI и переносить из нее точку синхроноизации в epoll_wait в nginx. Да, я верю что это возможно, но есть подозрение что придется этот OCI переделать.
И плохо что вы не написали что это только прототип. И в жизни это использовать нельзя.