Как бы вы архитектурно делали php скрипт, который должен долго работать, кушать прилично оперативы и при этом не падать internal server error?
День добрый.
Есть php скрипт, он работает долго и жрет много оперативы, скрипт не кроновый.
Чтобы на обычных хостингах он не выпадал в internal server error , скрипт сам себя перезапускает через file_get_contents .
Я понимаю, что это кривое решение.
Как бы вы архитектурно делали php скрипт, который должен долго работать, кушать прилично оперативы и при этом не падать в internal server error постоянно ?
Сделать скрипт кроновым или поднять до упора лимиты не вариант .
Перейти на питон тоже .
Я понимаю, что где-то в инете должно быть это расписано, но пара дней гугления выдала только старые блоги и промо статьи, если поделитесь ссылкой буду премного благодарен .
Делать демоны на PHP не стоит, не потому что оно не умеет или потому что медленно или потому что в случае ошибок оно всё умирает. Нет, просто потому что это всё сильно устарело и нет никакой необходимости тащить PHP как Legacy как таковой. Простой пример почему это плохо.
Сделайте вначале однопоточный нагруженный скрипт, который бы не упал по памяти в самый не ожиданный момент или не был убит сервером в случае сильной перегрузки ресурсов либо не убивающий отзывчивость всей системы в целом своей работой. Причём так что бы быть уверенным - пройдёт десять-двадцать-тридцать дней, а может и несколько месяцев с начала запуска и при постоянном количестве входных данных весь процесс его работы будет гладким, предсказуемым и безопасным. Вот когда напишите это на PHP можете смело считать себя не предсказуемым человеком. Ведь подумай вы обо всех нюансах заранее и сложив их со своим предыдущим опытом, поняли бы - это хороший язык программирования, но его время прошло. Но как технология, ReactPHP, конечно, интересная. Вряд ли такая уж крутая и вряд ли вам стоит делать на неё ставку в ближайшие пять-десять лет. Впрочем, PHP будут использовать ещё очень и очень долго...
(c) Oleg_Shevelev
Alexander Litvinenko: сколько пишу архиважные кроны, пхп не падает сам по себе. ошибки с базой, ошибки сокета, ошибки ещё хрен знает чего (логики), но пхп сам по себе не падает и нет утечек памяти
OnYourLips: ну и на ноде выжили, только как быть с "однопоточный нагруженный скрипт, который бы не упал по памяти в самый не ожиданный момент или не был убит сервером в случае сильной перегрузки ресурсов либо не убивающий отзывчивость всей системы в целом своей работой. ", например cr-works.net, написан на ноде, его апи живет в круглосудочном хайлоаде, парсит кучу сайтов каждые 20 минут, на однопоточном сервере с 512Мб.
Следить за тем, чтобы очищались ресурсы (delete context, mysql_free_result и тд) и переменные. gc сделает своё дело. не делать циклических ссылок. в остальном пхп достаточно хорош и нет таких memory leaks как у JS. вот nodejs я бы категорически не советовал для долгих скриптов.
Интересно узнать почему не советовалибы nodejs, вроде как он наоборот предназначен для этого, и в нем есть инструменты для очистки памяти, инструменты для асинхронной работы, кластеры, в конечном итоге даже расход памяти посмотреть там легче.
Alexander Litvinenko: на сколько я знаю nodejs нужен для быстрой отдачи контента. Если на нём делать какие-то тяжелые вычисления, то это приводит к блокированию. Но я только начал изучать nodejs и по этому могу ошибаться
а ещё алгоритм стоит разбивать на стадии и для долгих скриптов (месяцами которые крутятся) использовать shmem и хранить там так называемые снепшоты. иметь один главный процесс, который запускает дочерние и следит, чтобы те работали (как в апаче сделано), а те следят за главным. между рестартами процессов сохранять либо на диск, либо в shmem
romy4: =) у меня на работе есть практика, очень очень хорошая практика, которую мы применяем когда возникает спор двух айтишников, на счет технологий.
В основном споры возникают из-за непониманий техонологий друг друга, когда возникает спор, мы задаем всего два вопроса, после которых, в 90% случаев спор решаетса сам собой.
1. Назовыте три недостатка своей технологии.
2. Назовите три преимущества технологии конкурента.
В случае когда программист не может ответить, или говорит "недостатков нет", обычно это просто значит излишний фанатизм и скудные знания в области.
Я конечно оставлю эту ссылку здесь, и вы конечно понимаете какое это имеет отношение к утечкам, но всеже надеюсь вы еще и ответите на два вопроса выше, я могу ответить на них без труда.
Alexander Litvinenko: чувак, ты потерялся. скинь статью про пхп3 ещё. даже спорить с тобой не хочу. всего хорошего, "очень очень хороший практик" ты наш.
romy4: сразу видно, статью вы не прочитали, с утечками очевидно вы никогда дел не имели, вероятно не знаете даже как они возникают. Уверен, OnYourLips к примеру, ответ нашёлбы.
Средний
