zveb: Что код работает проверено на множестве проектов. Значит он вставлен либо: 1) не в том место, либо 2) скрипт ни чего не отдает (из-за !empty($output_buffer) буфер не очищается если очищать нечего), 3) приведенный мною код вызывается реже, чем в минуту.
Что бы сработало, скрипт должен в процессе работы что-то отдавать на выход. Если echo-ть нечего, то можно тупо печатать какой нибудь мусор. echo time() допустим.
Ярослав Астафьев: Впечатляет! Неужели там хватает ОЗУ на запуск JVM? Сейчас вот посмотрел htop и вижу, что Standalone Server резидентно забрал для себя 235Мб и замахнулся на 16Гб виртуальной. Видимо на Rasberry крутиться какой-то специальный вариант (embedded?)?
Ярослав Астафьев: Я так в принципе и делаю. Только запускаю Standalone Server ручками из шела после чего он висит в screen-е. А потом шлю команды через php-webdriver (в кой даже от меня висит пулреквест). Вот в этой схеме я и хотел отказаться от Standalone Server.
В любом случае спасибо за попытку помочь! Буду дальше копать уже в рассылке мозиловской.
Ярослав Астафьев: >Вы можете развернуть Selenium Grid - и конектиться к нему по Selenium RC\WebDriver
Как раз мой вариант. Запущенный Standalone Server (на 4444 порту, /wb/hub) принимает команды по WebDriver и запускает FF в котором они отрабатывают.
> Вы можете запускать FF нативно, использую FireFoxdriver, который и будет транслировать
> инструкции от вашей программы к FF.
Это в смысле через написание Java приложения? С полноценным пуском JVM?
Просто до возникшей баги в PhantomJS схема была простая. PhantomJS может пускаться демоном с поддержкой WebDriver команд. Дальше PHP скрипты по WebDriver им рулят. Все отлично работало и требовало памяти меньше, чем вариант с Java. Но есть сайт на котором в нем возникает JS ошибка undefined var, JS падает и не отрабатывает AJAX который там используется. Судя по описанию в буржунете это ошибка WebKit-а которая в настоящее время зафикшена. В в текущей версии PhantomJS используется старый WebKit с багой. Есть dev версия PhantomJS 2.0 в которой утверждается, что эта бага зафикшена (тупо ввиду использования более свежего WebKit). Но у меня на ununtu оно не завелось.
andreyvlru: статистика полученная через nginx-status (ngx_http_status_module) отражает состояние всего сервера вообще. Разделения на динамику/статику нет. Разделение на вхосты нет. В общем крайне куцая и использовать её для оценки возможностей бэкэнда неправильно.
Только динамические. Статика идет nginx-ом и который выполняет эту работу на отлично и проблем не возникает. А трафик на это приложении не такой. Это результаты нагрузочного тестирования которое выполнялось как раз с целью понять, сколько с одной машины можно потянуть.
Это же Java, так? Работает в рамках Selenium Java? Тогда не подходит, у меня как раз смысл не использовать Java, т.к. в проекте используется PHP. И раньше все работало через PhantomJS, но в нем оказалась одна бага которая не позволяет его использовать в некоторых случаях.
Про HeadLess не понял. Я знаю, что запускаю FF в HeadLess. Есть сервер с полноценным FF 33. Есть Xvfb обеспечивающий виртуальный дисплей. Есть Selenium Server Standalone который по сути является запускалкой FF (что хорошо видно через VNC Viewer подлюченный к дисплею и htop). Сейчас я хочу запускать FF фоном с тем, что бы слать ему webdriver команды напрямую. Упоминание о такой возможности я находил в доках, но вот конкретную реализацию не нахожу. Возможно какая-то недокументированная возможность (как например опция background для ff из cli которую использует Selenium Server и которой нет в мануале ff).
Мне так видится, что всилу контекстности порядка выполнения метод с приоритетами (весами) тут мало пригоден. Уже не говоря о том, что реализовать сложнее, чем явные правила.
@akubintsev да, быстрее и ресурсов ввиду сишности редиса уходит меньше. Поднятие нескольких демонов поднимает проблемы их синхронизации как ни крути (к примеру, у меня жесткое требование загрузки одного адреса гарантированно один раз, мы в Яндекс.XML ходим, а там лимиты жесткие). Конечно узкое место это соединение и асинхронка процесс ускоряет, но в однопоточном режиме это все равно медленее, чем многопоточная асинхронка предлагаемая мною. Кстати, ввиду использования DOM обработка результата - процесс сопоставимый с временем получения данных. Поэтому разница в итоге есть как по скорости работы, так и по реализации. Потому что стек на Redis это тупо вызов 2 функций: lPush и lPop.
Еще раз опишу используемую мною схему. Есть 2 скрипта висящих в cron, один формирует очередь, второй запущенный многократно берет из неё задания. Работает так.
1) Скрипт1 по минутному cron идет в базу и получает адреса которые нужно загрузить и фигачит их в Redis через lPush(). Через блокировку и запись pid файла гарантированно запускается строго в количестве одна штука при этом очередь заполняет строго если она пустая (дабы избежать дублирования и двойной загрузки).
2) Скрип2 по минутному cron запускается циклом while и идет в Redis беря один адрес через rPop(). Ввиду однопоточности Redis синхронизация пачки запущенных скрип2 не требуется, что сильно упрощает схему. Внутри себя он накапливает 100 адресов и через mCurl асинхронно их качает, строит DOM, тянет нужные данные, пишет данные в базу. Заканчивает работу через вызов rPop вернул пустой результат, т.е. очередь пустая.
В плане реализации схема очень простоя. Очень устойчива к ошибкам (и скрипт1 и скрипт2 могут дохнуть в любой момент по любой причине, логику работы приложения это не ломает, данные гарантированно остаются консистентными). И работает на хорошей для PHP приложения скорости. Потому что данные качает 100500-ая пачка асинхронных процессов (у нас хватает ресурсов на их запуск) которая к тому же успевает делать и парсинг, и запись в базу.
@akubintsev а это разве не вариант однопоточного демона ("прием входных данных через запрос, либо сделать циклический таймер для опроса очереди задач")? Конечно ассинхронного, но все же однопоточного? (по сути реализация того, что уже и так есть из коробки в виде Redis-а).
@Itvanya поскольку он не технический специалист, то из практического наблюдения он сделал неправильный вывод. Связи между тем, руками написан html или сгенерирован CMS-кой нет. Хотя бы просто потому, что снаружи сервера невозможно 100% сказать каким образом была получена страница. Другой вопрос, что делая себе страницу вы можете сделать код максимально компактным (CMS любят напихать мусора), семантически верным (разработчики CMS зачастую болт ложили на валидность верстки). А вот это уже влияет.
@zelenin админка самого сайта видимая часть приложения. Просто видеть её дано не всем. Поэтому админка сайта это НЕ бэкэнд. В это именно административная панель или так называемый бэкофис.
@deadbyelpy больших это сколько? И какого рода? Парсинг страничек? PHP с ним нормально справляется. Я это к тому, что откуда такая уверенность, что использование С решает проблему?
keepalive в данном контексте это вообще о другом.