1. Аргументируй такие громкие утверждения
2. А это уже не «горожение огородов»?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
оффтоп из «php программист»
- Автор темы grigori
- Дата начала
2. А это уже не «горожение огородов»?
cDLEON
Онанист РНРСlub
1) Отсутствие оверхеада на форки
2) Отсутствие оверхеада на "реинициализацию" приложения на каждый реквест (пусть даже частично это решается за счёт eaccelerator'a)
3) Отсутствие постоянно висящих форков, ожидающих ИО
4) Ну и остальные плюсы асинхронки...
А разве горожение?
1) с каких пор префорк-модель с "асинхронными" воркерами имеет дикий оверхед?
2) когда демон запущен, откуда реинициазизация?
3) они просят есть, занимают тыщи памяти, требуют денег до зарплаты?
4) плюсы да, есть. даже от простого select
Оверхед тут если и есть, то он точно не в форках и реинициазизациях
cDLEON
Онанист РНРСlub
Чукча, по всей видимости, не читатель. Там нет GIL и нет тредов. Там используются процессы в роли worker'ов и шаред мемори. А от префорка толку ноль при заявленных нагрузках.То есть, ты утверждаешь, что треды с GIL работают эффективнее префорк-модели. Записал
А, не, не утверждаешь, ты просто вообще уже сам не понимаешь, что говоришь. Сам приводишь в пример префоркалку и потом рассказываешь об "отсутствии оверхеда на форки" (который, вообще-то, настолько минимален, что говорить вообще не о чем - вообще-то форк уже 20 лет как везде copy-on-write).
cDLEON
Онанист РНРСlub
О каком демоне вы говорите?
о пхпшном, который делает то, о чем попросят: хошь генератор пакетов, хошь агрегатор. не принципиально
Слушай, перестань позориться. Тем более в разделе "работа". Лучше пойди изучи хоть что-нибудь. Вникая в суть, а не хватая слова не понимая их смысла. Ты вообще не понимаешь о чем говоришь, то что ты привел в пример это и есть префорк. Апач (mpm_prefork) и fpm работают ТОЧНО ТАК ЖЕ. И акселераторы ТОЧНО ТАК ЖЕ используют shared memory.
пошли по кругу уже, fixxxer уже писал
cDLEON
Онанист РНРСlub
Я, если честно, о тебе более лучшего мнения был. Ты прав. Спорить с неучем не вижу ни какого смысла
)) Тем более, что этот самый неуч делает выводы опираясь на собственную ограниченность.И я тоже писал о PHPDaemon. если что. Но на данный момент мы рассматриваем "классическую" схему. И вопросы я задавал применительно к ней.. Т.к. было очень интересно ПОЧЕМУ выбор пал именно на ПХП. Не более. Но как обычно набежали форумные тролли и начали мерятся знанием английских аббревиатур и "авторитетом".
cDLEON
Онанист РНРСlub
Что-нибудь о Twisted, Tornado etc. Слышали?
В каждом из них своя реализация ioloop, есть поддержка epool,kqueue, для обоих написаны разнообразные асинхронные библиотеки.
На данный момент я использую asyncmongo+tornado. Получаю огромные преимущества от реалтаймовой обработки запросов. Синтаксический сахар вроде питоновых генераторов (http://www.tornadoweb.org/documentation/_modules/tornado/gen.html) увеличивает читабельность и скорость разработки кода. Кроме того, сейчас вот прикрутил ко всему этому самописный монго-слейв. Который синхронизирует простейшие изменения в базе данных для каждого процесса.
Да, кстати. По поводу мультипроцессорности: http://www.tornadoweb.org/documentation/_modules/tornado/process.html вот реализация из коробки в этом самом tornado.
мы же рассматриваем классическую схему, не? т.е. какой-нибудь mod_wsgi или mod_python, не к ночи будет упомянут.
Мне кажется, то, о чем говорил фиксер в "ограничен одним сервером" - это проблемы локов и race condition.
Добраться до них трудно, но последствия от них будут фатальными.
Модель: на фронте 2 сервера, на них работает стая однопоточных демонов, которые собирают в своей памяти данные перед запросами в базу.
Самая вероятная проблема: база начинает упираться в i/o и лочиться на коммитах.
Получается, что пока процесс копит в памяти - все хорошо, но когда он ждет записи в базу - он залочен.
Можно сделать асинхронные запросы и получить шанс на пике положить базу насмерть, когда все процессы сделают по несколько асинхронных коммитов одновременно.
Выход - писать в nosql, разгребать отдельным процессом и в базу писать однопоточно.
Если у нас 2 сервера и 100 процессов php, которые пишут в memcached, нам нужен фоновый скрипт, который работает непрерывно, выбирает данные из memcached, обрабатывает и пишет в базу однопоточно.
Что именно нам пытаются доказать? На средних нагрузках модель связки однопоточных демонов эффективнее, чем модель связки однопоточных демонов и позволяет использовать два сервера вместо двух? Объясните, я не понимаю!
Добраться до них трудно, но последствия от них будут фатальными.
Модель: на фронте 2 сервера, на них работает стая однопоточных демонов, которые собирают в своей памяти данные перед запросами в базу.
Самая вероятная проблема: база начинает упираться в i/o и лочиться на коммитах.
Получается, что пока процесс копит в памяти - все хорошо, но когда он ждет записи в базу - он залочен.
Можно сделать асинхронные запросы и получить шанс на пике положить базу насмерть, когда все процессы сделают по несколько асинхронных коммитов одновременно.
Выход - писать в nosql, разгребать отдельным процессом и в базу писать однопоточно.
Если у нас 2 сервера и 100 процессов php, которые пишут в memcached, нам нужен фоновый скрипт, который работает непрерывно, выбирает данные из memcached, обрабатывает и пишет в базу однопоточно.
Что именно нам пытаются доказать? На средних нагрузках модель связки однопоточных демонов эффективнее, чем модель связки однопоточных демонов и позволяет использовать два сервера вместо двух? Объясните, я не понимаю!
cDLEON
Онанист РНРСlub
Мы рассматриваем классическую схему vs асинхронную. Я ни чего не имею против того же PHPDaemon. И его тоже можно рассматривать. Но вы влезли в разговор с аргументами, которые привожу я, в защиту фиксера.
Да. Есть такая проблема. Вообще, конечно, отталкиваться нужно от задачи. Конкретно моё предложение звучало как раз о том, что бы:
Если взять модель "баннерной системы", то как раз упереться в дисковый ИО можно только при огромном количестве инсертов. Я бы в таком случае попробовал бы минимизировать их количество ценой денормализации данных. Т.е. ввёл бы понятие "сессия", которая флашилась бы с уже подсчитанными показами за данный промежуток времени. Теперь смотрите. 50М хитов ~= 1к инсертов\сек(примерно) не денормализированных данных в пике. Пусть каждый клиент - уникальный,а время на флаш сессии 10 сек. Тогда раз в 10 секунд мы имеем всё те же 1к инсертов. За те 10 секунд "таймаута", я думаю, любая БД с любой конфигурацией хардов, разрулит эту нагрузку. К тому же тот же tornado будет держать с лёгкостью этот 1к коннектов даже на 1 одном ядре (если, например, сами баннеры отдавать через редирект на nginx.) Т.е. по-сути и масштабировать то, оказывается, не чего!!!
Естественно цифры взяты из головы и ни на какую точность не претендуют. Как и я, собственно, не претендую на гениальность. Прошу прощения если получается через-чур сумбурно, бессонная ночь...
cDLEON, возможно, тебе стоит определится, о чем именно ты говоришь. А то ты убеждал на прошлой странице, что все надо делать на «скриптах-однопоточниках» а потом приводишь ссылки, что в Twisted есть многопоточность. Как говорится, ты или крестик сними, или...