Лимит на реальное (не процессорное!) время работы скрипта

Vasya · 16 Июн 2005

Насчет "пропатчивания" - хотелось бы обойтись без. Потому что это снижение переносимости на сей раз.

Понимаю

Но, оборачивание вызова ibase_query(); прямо в PHP, кажется мне совсем ненадежным вариантом. Кто-то обязательно что-то забудет. Тем более, если на хостинге не один PHP программист. Тут imho как раз надо спуститься уровнем пониже.

2. Есть ещё более дикая идея. Сделать прокси для соединения с базой. То есть, PHP соединяется с базой через некий порт на котором висит нечто, что транслирует запросы уже к самой базе. Это нечто очень умное, оно видит, когда пошел запрос и отмеряет ему 10 секунд. По истечение их, отвечает, что мол ошибка в ДНК у запроса.
Ну, для полноты картины...

si · 16 Июн 2005

Dmitry Koteroff

> unlink($fname);
Ага. Вот не дойдет до этого оператора дело, и останется файл мусорный висеть

тоже самое будет и с env (даже если бы было возможно его читать), и с сокетами и т.п

получим засорение /tmp временными файлами, которые некому чистить

имхо надуманная проблема

масштабируемостью

мне кажется это слово вообще имеет другой смысл, и про маштабируемость я не помню чтобы в этом топике вообще поднимался разговор.

все решения в данной ситуации это костыли, не хотите костылей - надо или менять софт, или архитектуру приложения, чтобы такие запросы вообще не в скрипте обрабатывались,
а неком посреднике, с которых была бы не блокирующая связь. только стоимость такого решения гораздо выше будет, люби готовы платить за такие решения ?

Vasya · 16 Июн 2005

Потому что это снижение переносимости на сей раз.

А теперь не понимаю. Снижение переносимости чего? Хостинга?

PHP код-то не будет затронут никак...

si · 16 Июн 2005

я вообще склоняюсь что вам не надо решение, вам шашечки надо

-~{}~ 16.06.05 01:06:

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

-~{}~ 16.06.05 01:11:

предлагаю беседу перенести завтра в IRC на #phpclub.ru

AnToXa · 16 Июн 2005

2. Есть ещё более дикая идея. Сделать прокси для соединения с базой. То есть, PHP соединяется с базой через некий порт на котором висит нечто, что транслирует запросы уже к самой базе. Это нечто очень умное, оно видит, когда пошел запрос и отмеряет ему 10 секунд. По истечение их, отвечает, что мол ошибка в ДНК у запроса.
Ну, для полноты картины...

вот это и есть простенький application server, взять тот же memcached и чуть подкрутить, ну не совсем чтобы чуть, но не так сложно.

Vasya · 16 Июн 2005

вот это и есть простенький application server

Таким образом, похоже, что мы перебрали все варианты.

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

Ага. "Чуть-чуть" разобрать весь протокол общения клиента IB с сервером %)

si · 16 Июн 2005

вот это и есть простенький application server, взять тот же memcached и чуть подкрутить, ну не совсем чтобы чуть, но не так сложно

знаааачительно сложнее варианта touch($fname);

AnToXa · 16 Июн 2005

знаааачительно сложнее варианта touch($fname);

ну автору топика ведь шашечки нужны, а не ехать

Ага. "Чуть-чуть" разобрать весь протокол общения клиента IB с сервером %)

совершенно не нужно

Dmitry Koteroff · 16 Июн 2005

AnToXa, ладно, проехали.

Будут еще мысли у кого-нибудь - менее слонопотамоподобные?

si · 16 Июн 2005

ну автору топика ведь шашечки нужны, а не ехать

тогда app server как раз то что надо

alexhemp · 16 Июн 2005

Патчить Firebird на предмет добавления LOCK_TIMEOUT из Yaffil

Вот это будет грамотное решение ;-) Остальные будут "костыли" и "немасштабируемые".

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

Dmitry Koteroff · 16 Июн 2005

> Но, оборачивание вызова ibase_query(); прямо в PHP,
> кажется мне совсем ненадежным вариантом. Кто-то
> обязательно что-то забудет. Тем более, если на хостинге
> не один PHP программист. Тут imho как раз надо спуститься
> уровнем пониже.
Вы, конечно, правы, и в идеальном мире надо было бы так и поступить, расширив API IB и введя туда тайм-ауты. Тут есть, правда, одна проблема: программист ведь сам должен решать, какая задержка приемлема для того или иного запроса (как тут было правильно замечено, бывают совершенно легальные запросы, длящиеся дольше 10 секунд).

Про "забудет" на данном уровне, на самом деле, речи не идет, потому что вся работа с IB идет через единый интерфейс. Можно "забыть", если напрямую вызвать ibase_query(), но это вряд ли кто будет делать. Задача решается не на уровне всего хостинга, а, грубо говоря, на уровне группы отдельно взятых проектов на этом хостинге.

Решение, конечно же, хотелось бы максимально изящное - без всяких там прокси-серверов, файлов, сокетов, разделяемой памяти и т.д. С другой стороны, и без патченья PHP и FB.

Ладно. Видимо, придется все же вернуться к варианту с "долбежкой" NOWAIT-запросов до тех пор, пока не пройдет (если ничего другое не придумается).

> ну автору топика ведь шашечки нужны, а не ехать
Слишком далеко идущие выводы. Как говорится в известном анекдоте, "спили мушку!". В смысле, смените подпись.

)

Vasya · 16 Июн 2005

Про "забудет" на данном уровне, на самом деле, речи не идет, потому что вся работа с IB идет через единый интерфейс. Можно "забыть", если напрямую вызвать ibase_query(), но это вряд ли кто будет делать.

Очень, очень хорошо. Похоже, у вас идеальные условия.

Решение, конечно же, хотелось бы максимально изящное ... придется все же вернуться к варианту с "долбежкой" NOWAIT-запросов...

Йес!

Вот ещё один вариант. Пропатчить php_interbase таким образом:
- если в $_ENV имеется переменная IB_QUERY_TIMEOUT > 0, то перед стартом isc_dsql_execute() создается дочерний трид с таймером выставленном на это значение.
- после выхода из isc_dsql_execute() этот трид прибивается родителем
- по истечение таймаута, дочка выдает сообщение об ошибке и завершает весь процесс, типа exit();
Тут и гибкость -- можно настраивать как группу, так и единичные запросы; и "немонстровидность" -- никаких демонов и проксей; и интерфейсность -- сообщение об ошибке.

alexhemp · 16 Июн 2005

Dmitry Koteroff

Если длинная транзакция нечастое явление, то вполне будет достаточно скажем 3-х повторений через секунду и возврат в форму с сообщением об ошибке.

Dmitry Koteroff · 16 Июн 2005

Возла тут еще одна идейка - как без демона обойтись. В принципе, если использовать разделяемую память (shm_*) и писать статусы туда, а зажравшиеся процессы прибивать kill-ом ПРЯМО ИЗ СКРИПТА (при его старте), это нельзя назвать понижением масштабируемости - ведь данную функциональность можно реализовать в виде отдельной автономной PHP-библиотеки с простым интерфейсом. Иными словами, библиотека - "черный ящик" (в отличия от случая с демоном, который назвать "черным ящиком" нельзя ну никак).

Главное, права на kill у скрипта ЕСТЬ, потому что все скрипты одного сайта гарантировано запускаются под одним и тем же UID-ом! И накладных расходов почти никаких нет.

Единственный минус - процессы будут прибиваться только при запуске очередного скрипта на сайте. Впрочем, если сайт имеет определенную посещаемость, это не должно быть особенной проблемой. К тому же - можно через cron дергать какой-нибудь скрипт (по wget) раз в минуту, чтобы все чистилось.

Попробую, видимо, так сделать.

si · 16 Июн 2005

Dmitry Koteroff
получаем теже глабли что и в файлами

Ага. Вот не дойдет до этого оператора дело, и останется файл мусорный висеть

Dmitry Koteroff · 16 Июн 2005

Ну и какой тут мусорный файл для случая с разделяемым сегментом памяти? Процесс умер, сегмент освободился автоматом, разве нет?

http://ru3.php.net/manual/en/function.shmop-open.php

si · 16 Июн 2005

Процесс умер, сегмент освободился автоматом, разве нет?

при таком раскладе у вас вообще ничего работатеь не будет

fisher · 16 Июн 2005

а не пробовали прикинуть какова верятность возникновения бесконечно долгих транзакций и просто долгих транзакций (которые мы потеряем перейдя на NOWAIT)? имхо самое правильное - это имеено тупое решение: долбить с NOWAIT, usleep, и так макисмум N раз а если не смогла - ну, привет. аргументы помимо простоты: если у вас такое происходит часто, вам никакие ухищрения не помогут. прибитый процесс суть та же отвалившаяся пользовательская транзакция, и ещё непонятно - так уж ли необходимо ей дорожить: в угоду одной транзакции вы "подставляете" все остальные, и я не найду сходу предметную область помимо банковских операций, где ответ на вопрос "а стоит ли" неоднозначен.

ONK · 17 Июн 2005

Я не понимаю, чем не устраивает вариант с файлами. Это самое просто и вполне надёжное решение.

Лимит на реальное (не процессорное!) время работы скрипта

Vasya

Guest

Administrator

Vasya

Guest

Administrator

prodigy-одаренный ребенок

Vasya

Guest

Administrator

prodigy-одаренный ребенок

Dmitry Koteroff

Guest

Administrator

Новичок

Dmitry Koteroff

Guest

Vasya

Guest

Новичок

Dmitry Koteroff

Guest

Administrator

Dmitry Koteroff

Guest

Administrator

накатила суть

Пассивист PHPСluba