php-скрипты с большим временем исполнения
Подскажите: бывают ли php (или perl) скрипты со временем работы, измеряемым десятками минут? Если да, для чего могут использоваться?
Все бывает.
Например, для подсчета факториала от 1000000 или можно генерировать адреса перебором букв англ. алфавита и коннектится к ним, чтобы узнать, сколько в инетрнете осталось свободных адресов длинной до 20 букв :)
А вот встречный вопрос:
Бываю ли такие пользователи интернета, которые готовы ждать десятки минут чтобы увидеть результат работы php (или prel) скрипта??
А вот встречный вопрос:
Бываю ли такие пользователи интернета, которые готовы ждать десятки минут чтобы увидеть результат работы php (или prel) скрипта??
Да не надо ничего ждать, если этот скрипт, допустим, постоянно работает и результаты в базу пишет. Или в файлы, не важно. Например, робот поисковый. Кстати, на чем их пишут?
Да не надо ничего ждать, если этот скрипт, допустим, постоянно работает и результаты в базу пишет. Или в файлы, не важно. Например, робот поисковый. Кстати, на чем их пишут?
На чем могут на том и пишут :)
Что это за странные вопросы? Что нибуть по существу можно?
Время жизни скрипта определяется:
- поставленной задачей
- настройками скрипта или интерпритатора(скрипт может умереть еще до окончания своей работы)
- настройками сервера(квоты на процессорные ресурсы увеличивают время работы, квоты на время не дадут скрипту работать больше разрешенного времени)
Подскажите: бывают ли php (или perl) скрипты со временем работы, измеряемым десятками минут? Если да, для чего могут использоваться?
Бывают.
Spam рассылать например ;)=
Что это за странные вопросы? Что нибуть по существу можно?
Просто недавно столкнулся с сабжем. А поскольку привык, что
max_execution_time = 30, создал эту темку. Спасибо всем за ответы.
Друзья, у меня вопрос: существует ли возможность обойти ограничение хостинга в max execution_time =30 , и заставить работать скрипт долго, не вываливаясь... Например в цикле?
Вариант записывать состояние и слать refresh мне не особо нравится.
Можете посоветовать что-то по этому поводу?
Нет не существует. Единственный вариант записывать состояние и вызывать извне или по CRON
Неправда... У меня написан бот для популярного в Украине чата bizarre так вот когда я его в браузере запускаю, он пашет условно до бесконечности...
Может fsockopen виноват?
Фрагмент кода:
if($socket)
{
print "Request sent...\n";
flush();
while(!feof($socket))
{
$str = fread($socket, 4096);
echo $str;
flush();
}
}
На хосте отвечает поток stream.pl (CGI скрипт, как я понимаю)... или он виноват???
Никаких ini_set('max_execution_time',0) не стоит
phpinfo()
max_execution_time 30
[QUOTE="http://www.php.net/manual/en/info.configuration.php#ini.max-execution-time"]max_execution_time integer
This sets the maximum time in seconds a script is allowed to run before it is terminated by the parser. This helps prevent poorly written scripts from tying up the server. The default setting is 30. When running PHP from the command line the default setting is 0.
The maximum execution time is not affected by system calls, stream operations etc. Please see the set_time_limit() function for more details.[/QUOTE]
[QUOTE="http://www.php.net/manual/en/function.set-time-limit.php"]Note:
The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running.[/QUOTE]
Если бы я знал где именно это искать в мане, не писал бы на форум, где есть вы, умные и просветленные и любящие помогать.
Т.е. для того, чтобы скрипт висел долго, нужно всего лишь открыть поток или системный вызов, который будет висеть и не давать скрипту отвалиться... а в цикле делать всё что необходимо...
Вопрос: если браузер отвалится - не будет ли при этом скрипт продолжать висеть на сервере в цикле?
Гоняешь как? Перезапуском скрипта с записью состояния? Или из командной строки?
Зависит, вроде как, от какой-то надстройки в php.ini. От какой - не помню и искать лень. В общем, если флаг установлен, допустим, то скрипт будет выполняться до тех пор, пока жив клиент (я так понимаю, зависит от Connection: keep-alive/close); а иначе - пока скрипт не выполниться.
Зависит, вроде как, от какой-то надстройки в php.ini. От какой - не помню и искать лень. В общем, если флаг установлен, допустим, то скрипт будет выполняться до тех пор, пока жив клиент (я так понимаю, зависит от Connection: keep-alive/close); а иначе - пока скрипт не выполниться.
connection_aborted()
Вопрос, какой системный вызов или поток открыть, чтобы он не жрал ресурса, но заставлял жить скрипт...?
Правда. Поверь более старым и опытным людям. Что до указанного файлика, то расширения pl ни на какие мысли не наводит? Мне вот видится, что это perl и ни каким боком тут max_execution_time работать не может, ведь это директива PHP.
Поэтому в контексте хостера у которого max_execution_time лимитирован и в рамках PHP ответ однозначный: превысить лимит max_execution_time в рамках одного запроса невозможно.
Отсюда совершенно не следует, что реализовать псевдодемона невозможно. Но для этого придется привлечь сторонние средства. К примеру, крон. Или из браузера через JavaScript, даже через упомянутый банальный рефреш страницы через мета-тег. Кроме того нужно сохранять состояние работы между запросами, если логика работы однопоточная делать синхронизацию между процессами (через семафоры, лок-файлы). Но такое приложение назвать чисто PHP-шным нельзя.
У меня была когда-то задача - то ли сграбить, то ли скачать и обработать очень много данных. В общем, файлов было много, объемы килобайт 50-100. Качать через свой канал смысла не было, ибо узкий. Решил обрабатывать через хостинг. Решалось все стандартным header("this_page.php?param1=...¶m2=..."); тем самым за 5-6 часов была выполнена задача. Вот такие псевдо-демоны или долгие процессы.
Не обязательно. У рефреша минус - нужно держать страницу открытой в браузере. Вообще в контексте упомянутых тобою условий можно было сделать рекурсивный вызов. Т.е. когда скрипт работает max_execution_time-10 после чего по URL вызывает сам себя (cURL, file_get_contents, etc) и мы снова имеем max_execution_time секунд для работы. Минус в том, что если в ходе работы скрипт упадет или сдохнет, то он не сможет перезапустить сам себя и работа остановиться. Поэтому из браузера все же стоит скрипт попинывать, только делать это можно уже не каждые max_execution_time, а раз в час к примеру.
Гы-гы.. Реально ты мне сейчас напомнил меня в диалогах с RussianSpy...
Что толку умничать про хостера, если тазик где выполняется PHP-скрипт стоит у меня за спиной, а хост с файликом .pl вообще в Киеве...
То, что чат отдаёт поток - мне по сараю... ПХП-скрипт-то у меня на другом хосте и открыт в браузере...
Почему работает - в ответе UAS на предыдущей страницы... Открытые сокеты сводят max_executin_time на нет...
теоретически - открываем сокет с (теоретически) неограниченным временем выполнения и всё... можем работать... Что, в принципе, технически не верно...
По-этому для задач, которые требуют длительного выполнения, наверное и создан консольный PHP... Но, наверняка нельзя, обращаясь к веб-серверу, вызвать выполнение PHP-скрипта в консоли?
Ваша манера общаться отбивает всякое желание вам отвечать. К сожалению, еще раз кинуть вам минус в карму не могу, но я призываю к этому других участников.
Что толку умничать про хостера, если тазик где выполняется PHP-скрипт стоит у меня за спиной, а хост с файликом .pl вообще в Киеве...
В огороде — бузина, а в Киеве — дядька.
В первоначальном топике об этом не было ни слова. Поэтому на вопрос, можно ли обойти хостинговое ограничение max_executin_time однознаный по прежнему - нет.
Спасибо за оффтопик. Как всегда, кроме бесполезняшек от тебя постов нет. Так зачем ты пишешь? Неудовлетворённое желание флудить и оффтопить?
Купи себе навигатор (желательно на 5" экран), там ты обязательно найдёшь дорогу туда, куда на форуме посылать не принято.
Предстоящая цель - разбор больших массивов данных (чуть меньше, чем у int, но всё же)... Данные будут представляться в XML-файле. отсюда и необходимость "одним махом" всё протолкнуть, чтобы не перечитывать по новой XML.
Дык, это ж некротопик... ТС задавал вопрос в 2005 году :) Так что я вопрос написал от себя на предыдущей странице, т.к. нет смыла плодить новые топики )
Дело в том, что указанный скрипт с fsockopen работал и на виртуальном хостинге... Точнее, на двух разных (X-Host, HOSTPRO), и в то время когда скрипты, работающие с БД и над файликами действительно отваливались, этот работал дальше. МБ повезло с хостерами? )
А вот по поводу второй части - пойду покурю маны, спс... Хотя такую штуку на виртуальных хостингах наверняка закрыли... будем читать...
Купи себе навигатор (желательно на 5" экран), там ты обязательно найдёшь дорогу туда, куда на форуме посылать не принято.
Предстоящая цель - разбор больших массивов данных (чуть меньше, чем у int, но всё же)... Данные будут представляться в XML-файле. отсюда и необходимость "одним махом" всё протолкнуть, чтобы не перечитывать по новой XML.
Ты бы хамил поменьше, парниша, а побольше мануалы читал.
Дело в том, что указанный скрипт с fsockopen работал и на виртуальном хостинге... Точнее, на двух разных (X-Host, HOSTPRO), и в то время когда скрипты, работающие с БД и над файликами действительно отваливались, этот работал дальше. МБ повезло с хостерами? )
А вот по поводу второй части - пойду покурю маны, спс... Хотя такую штуку на виртуальных хостингах наверняка закрыли... будем читать...
Из тех обрывков информации что я вижу в постах в данном топике могу предположить, что у одного хостера висел первовый скрипт демоном который держал коннекты с клиентами, бэкэндом к нему работал PHP которые осуществлял работы с базой. Это не везение или невезение с хостерами, это просто такая схема использования. По мне, уж коль скоро использоваться перл, было бы логично из него же работать и с базой.
А такую штуку не наверняка, а точно закрыта у всех адекватных хостеров. А там, где она открыта запуск внешних программ зажат в такие клещи, что толку от них немного. Собственно поэтому шаред хостинг вполне подходит для создание динамических страничек, но ни как не для написание демонов. Демонописалей же хостер быстро заруливает на VPS/VDS. Поэтому на PHP шаред-хостинге невозможно написать полноценный демон (понимая "демон" в юниксовом контексте, т.к. как долгоживуй процесс без родительского шела).