Комментарии 16
Спасибо! Крайне интерестно для использования роботостроении.
Спасибо, почаще бы выходили такие статьи. Распараллеливание вычислений, одно из важных в разработке, так как web любит скорость…
доступ к web информации из БД — это как formula-1 :)
доступ к web информации из БД — это как formula-1 :)
Не знал. Спасибо за весьма полезную информацию!
НЛО прилетело и опубликовало эту надпись здесь
такие штуки прикольно делать с большими объёмами данных, например, для баз данных. чтобы не ждать пока оно запишется/прочитается, а заниматься подкотовкой ещё чего-нибудь.
но в этом всём есть свой большой минус. если, допустим, использовать по 5 дополнительных процессов на каждый скрипт, то при нормальной нагрузке можно забить всю очередь апача. тогда выйдет проигрышь, нежели выполнять всё в 1 потоке.
но в этом всём есть свой большой минус. если, допустим, использовать по 5 дополнительных процессов на каждый скрипт, то при нормальной нагрузке можно забить всю очередь апача. тогда выйдет проигрышь, нежели выполнять всё в 1 потоке.
Поправьте меня, если я ошибаюсь, но в данном случае никаких дополнительных процессов не запускается. stream_select() просто «опрашивает» сокеты на предмет доступности и делает это до тех пор, пока какие-то из них не станут доступны или же не наступит тайм-аут. Все происходит в одном процессе.
в зависимости от настроек сервера. Допустим, сервер будет апач, то в зависимости от версии будут запускаться либо новые процессы (1. х ) либо новые потоки (2. х) при отсуствии свободных. А свободные с большим расходом быстро забьются. Для ethernet сайтов это хорошее решиние. Для интернет сайтов, расчитаных на посещаемость съест быстро все свободные ресурсы. Чревато получением #500.
Сие можно извратить и использовать отдельный соседний (входящий в одну подсеть) сервер для приёма данных в базу данных. Тогда выигрышь ощутим. Если в подсеть отключить от внешних «раздражителей», то для систем с большой обработкой данных (а не генерацией страниц, как это обычно бывает) получим хороший выигрышь.
Только тогда PHP уже не сильно подходит как язык написания таких систем.
Сие можно извратить и использовать отдельный соседний (входящий в одну подсеть) сервер для приёма данных в базу данных. Тогда выигрышь ощутим. Если в подсеть отключить от внешних «раздражителей», то для систем с большой обработкой данных (а не генерацией страниц, как это обычно бывает) получим хороший выигрышь.
Только тогда PHP уже не сильно подходит как язык написания таких систем.
Мне кажется, вы слишком большое внимание уделили приведенному мной примеру, и слишком маленькое — собственно технологии. Совсем необязательно, что открытые сокеты будут прослушиваться апачем или другим веб-сервером, совсем необязательно использовать при этом протокол HTTP. Это могут быть, например, сокеты, которые слушает поисковый демон «Сфинкс» или еще что угодно.
Важно то, что мы сами «слушаем» события на этих сокетах и, как только те или иные из них становятся доступны — принимаем с них данные и эти данные обрабатываем, тогда как в традиционном подходе пришлось бы открыть сокет, дождаться, пока станет возможно считать оттуда что-то, считать, закрыть сокет и перейти к следующему, чтобы повторить все сначала.
Важно то, что мы сами «слушаем» события на этих сокетах и, как только те или иные из них становятся доступны — принимаем с них данные и эти данные обрабатываем, тогда как в традиционном подходе пришлось бы открыть сокет, дождаться, пока станет возможно считать оттуда что-то, считать, закрыть сокет и перейти к следующему, чтобы повторить все сначала.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
распараллеливаем выполнение задач с помощью stream_select()