Pull to refresh

Comments 16

Спасибо! Крайне интерестно для использования роботостроении.
Какое PHP в роботостроении? Робот с web-сервером внутри? :)
Речь про роботов поисковых машин, например.
По-моему такое на PHP неоправданно писать, хотя может быть я и ошибаюсь.
Тоже делаю роботов. Статья действительно ценная. Спасибо!
Спасибо, почаще бы выходили такие статьи. Распараллеливание вычислений, одно из важных в разработке, так как web любит скорость…
доступ к web информации из БД — это как formula-1 :)
Не знал. Спасибо за весьма полезную информацию!
вот за filter_input вам благодарен… правда теперь я понял, что фреймворки вообще нах не нужны…
такие штуки прикольно делать с большими объёмами данных, например, для баз данных. чтобы не ждать пока оно запишется/прочитается, а заниматься подкотовкой ещё чего-нибудь.

но в этом всём есть свой большой минус. если, допустим, использовать по 5 дополнительных процессов на каждый скрипт, то при нормальной нагрузке можно забить всю очередь апача. тогда выйдет проигрышь, нежели выполнять всё в 1 потоке.
Поправьте меня, если я ошибаюсь, но в данном случае никаких дополнительных процессов не запускается. stream_select() просто «опрашивает» сокеты на предмет доступности и делает это до тех пор, пока какие-то из них не станут доступны или же не наступит тайм-аут. Все происходит в одном процессе.
в зависимости от настроек сервера. Допустим, сервер будет апач, то в зависимости от версии будут запускаться либо новые процессы (1. х ) либо новые потоки (2. х) при отсуствии свободных. А свободные с большим расходом быстро забьются. Для ethernet сайтов это хорошее решиние. Для интернет сайтов, расчитаных на посещаемость съест быстро все свободные ресурсы. Чревато получением #500.

Сие можно извратить и использовать отдельный соседний (входящий в одну подсеть) сервер для приёма данных в базу данных. Тогда выигрышь ощутим. Если в подсеть отключить от внешних «раздражителей», то для систем с большой обработкой данных (а не генерацией страниц, как это обычно бывает) получим хороший выигрышь.

Только тогда PHP уже не сильно подходит как язык написания таких систем.
Мне кажется, вы слишком большое внимание уделили приведенному мной примеру, и слишком маленькое — собственно технологии. Совсем необязательно, что открытые сокеты будут прослушиваться апачем или другим веб-сервером, совсем необязательно использовать при этом протокол HTTP. Это могут быть, например, сокеты, которые слушает поисковый демон «Сфинкс» или еще что угодно.

Важно то, что мы сами «слушаем» события на этих сокетах и, как только те или иные из них становятся доступны — принимаем с них данные и эти данные обрабатываем, тогда как в традиционном подходе пришлось бы открыть сокет, дождаться, пока станет возможно считать оттуда что-то, считать, закрыть сокет и перейти к следующему, чтобы повторить все сначала.
возможно, да, я однобоко смотрел исключительно отталкиваясь от примера.
маленькое замечание.
sockets != streams
хоть и похожа обработка. сокеты очень быстрые. потоки — по всякому бывает.
Согласен, уже и сам посмотрел на свои комментарии и понял, что использую то один термин, то другой, в то время как на самом деле речь только о потоках.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.