-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
оффтоп из «php программист»
- Автор темы grigori
- Дата начала
cDLEON
Онанист РНРСlub
флоппик
Не, я, может быть, выражаюсь не правильно, прошу прощения.
Я говорю не о _много-поточности_, а о _много-процессорности_. Где количество процессов данного приложения = количеству ядер сервера(что бы загрузить все ядра сервера). А внутри каждого процесса как раз однопоточник, который рулит соединениями через тот же epool
Не, я, может быть, выражаюсь не правильно, прошу прощения.
Я говорю не о _много-поточности_, а о _много-процессорности_. Где количество процессов данного приложения = количеству ядер сервера(что бы загрузить все ядра сервера). А внутри каждого процесса как раз однопоточник, который рулит соединениями через тот же epool
ключевые слова "если есть" В случае с ПХП - вероятность стремится к 0
Чукчанечитатель-чукчаписатель?
Раз в 10 секунд, пока будет выполняться коммит, твой супербыстрый демон будет висеть 1 секунду залоченый на mysql_query, выстраивая очередь из тысячи запросов, или ты будешь выполнять асинхронный запрос, или создавать новый поток для работы с базой?
Серверов на фронте будет минимум два для резервирования, в каждом минимум по 4 ядра - других давно нет, говнохостинги и экономию $100/мес не рассматриваем.
Повторяю вопрос: Что мы оптимизируем?
cDLEON
Онанист РНРСlub
В случае с prefork_mpm внутри создаются Thread'ы в моей модели нет ни каких thread-ов внутри, там один общий while, который делят между собой все.
cDLEON
Онанист РНРСlub
Григорий, я прекрасно понимаю о чём ты! Боюсь, что объяснять я действительно не умею. На данный момент абсолютно не важно синхронка или асинхронка для доступа к БД там будет использоваться. Ты же понимаешь, что записывая уже подсчитанные данные за эти 10 секунд, мы уже уменьшили нагрузку на диск в 10 раз? Почему ты всё равно настаиваешь на локе из-за ИО ? Ведёшь к тому, что это не горизонтальное масштабирование? Ну так и твоя схема не идеальна и имеет точно такие же проблемы. Только в твоём случае извращаться придётся с мемкешем. И даже если писать в базу в один поток - да, мы, практически, получаем 99% защиту от дедлока, но мы не решаем проблему с дисковым ИО. А наоборот ещё больше её усугубляем запутанностью логики, проблемами, связанными, с архитектурой мемкеша - например кусок данных, который, как бы ещё не записан, "вытесняется" новой порцией! Получим вдовесок необходимость в "прогревании кеша".
Что мы оптимизируем? Расходы на это самое горизонтальное масштабирование.
cDLEON
Онанист РНРСlub
Ребят, я реально не понимаю, что я описываю не так. С моей стороны это выглядит как сломанный телефон. Я, вроде как, пытаюсь донести свою мысль, а меня постоянно пытаются уличить в том, что я "сам дурак" и в то же время не приводят ни каких разумных аргументов. Григорий - исключение. В итоге получается какой то срач, хотя целью для меня было как раз обсудить "не шаблонный" вариант и выяснить принципиальные подводные камни.
У кого общий while? У всех однопоточных процессов висящих по отдельности?
prefork_mpm бывает как и на тредах, так и на процессах, и даже гибридный — с раздельными процессами, которые еще делятся на треды
Никуда ты не денешься от архитектуры ОС — наивно же думать, что в питоне свои, «особенные» процессы, которые ничего общего с остальными не имеют.
А если ты говоришь об архитектуре системы — то какая разница, пхп там или питон?
Я же говорю, ты определись, о чем ты говоришь.
Тебя пытаются уличить что «сам дурак» потому что ты постоянно от темы к теме прыгаешь, и собственные же граничные условия передвигаешь. Выглядит это естественно так, что ты не понимаешь, о чем говоришь. (Возможно потому, что пытаешься говорить сразу обо всем)
cDLEON
все, я понял, если у тебя все расчеты - это инкремент показов по баннерам и простенький геотаргетинг без расчета временных зон и радиусов, это вписывается в 1 ядро, ты на лету агрегируешь данные перед записью и первичные данные тебе вообще не нужны, то да - "640 кб хватит для всех"
как-бы да, понятно, удачи в будущем
флоппик забей, человек просто не выспался
все, я понял, если у тебя все расчеты - это инкремент показов по баннерам и простенький геотаргетинг без расчета временных зон и радиусов, это вписывается в 1 ядро, ты на лету агрегируешь данные перед записью и первичные данные тебе вообще не нужны, то да - "640 кб хватит для всех"
как-бы да, понятно, удачи в будущем
флоппик забей, человек просто не выспался
cDLEON
Онанист РНРСlub
Так-с... У каждого процесса по одному:
PHP:
while (true) {
}Мне без разницы на чём написан этот самый однопоточник. Просто в надёжность PHPDaemon я не верю.
Разговор я пытаюсь вести как раз об архитектуре.
Говорю "обо всём", потому, что мне приходится отбиваться сразу от нескольких аппонентов и ни кто мне не помогает
То есть если я запущу 4 копии баша, он внезапно становится многопроцессорным?
О чем я как бы и говорю — твои аргументы на уровне твоих же домыслов. Они не основаны на каких-то фактах и сравнениях. Просто — «не нравится». Разве это разговор об архитектуре?
cDLEON
Онанист РНРСlub
Григорий, все данные для этих расчётов легко ложатся на начальном этапе прям в память и синхронизируются с сервером по таймауту. Зачем там нужны ещё какие то выборки\апдейты на каждый реквест? Тем более, что выборки можно делать уже с слейвов.
Кроме того, мы с тобой обсуждаем сферическую баннеро-крутилку. И если хочешь поговорить более детально - предоставь ТЗ
Тогда можно будет оговорить конкретную архитектуру, конкретного проекта. Если, конечно, желание есть А почему нет? Эти 4 копии баша смогут выполнятся разными процессорами? http://ru.wikipedia.org/wiki/Многопроцессорность
Так я разве обсуждаю PHPDaemon ? Я его просто стараюсь не касаться вообще, в рамках данного разговора.
Ну twisted с tornado ты же касаешься в рамках этого разговора.
cDLEON
Онанист РНРСlub
Ну здесь то я опираюсь на собственный опыт, бенчмарки - которых полно в интернете, собственные бенчмарки и опыт.
alekciy
Новичок
Ты сильно заблуждаешься.
alekciy
Новичок
Точная определенность по терминам - залог сохранности нервных клеток.
Многопроцессорность - наличие в системе на аппаратном уровне более чем одного процессора. Это аппаратное понятие. Приложение запущенное N раз (где N равно числу процессоров) вовсе не обязательно должно выполнятся на N процессорах. Даже в многопроцессорной системе все копии могут оказаться на одном процессоре. Получаем классическую многозадачную работу.
Многопроцесность - запуск приложения несколько раз с созданием на уровне ОС процессов. Понятие софтерное. Это при этом приложение не было рассчитано на запуск в многопроцессорной системе (т.е. не может себя раскидать под N процессорам), то два ОС процесса этого приложения вполне могут попасть на один процессор. Т.е. работа приложения вырождается в многозадачный режим работы.
В принципе теоретически на уровне планировщика ОСи можно придумать хитрые алгоритмы по которым бы процессы одного приложения раскидывались по разным ядрам. Возможно сейчас что-то такое и есть, но когда я последний раз интересовался этим вопросом, то автору приложения нужно было самостоятельно предусмотреть возможность работы на многопроцессорных системах. Впрочем как и для случая работы в тредовом режиме. В общем не знаю как там в питоне, но вот VM erlang-а может быть запущена в режиме работы на прогопроцессорной системе.
Не знаю, на сколько четко ты это понимаешь. Возможно понимаешь, но плохо излагаешь. Но если прочесть эту тему, то складывается впечатление, что ты постоянно "путаешься в показаниях" и допускаешь явные ляпы по ходу обсуждения. Что говорит о явном хаосе в представления касающихся схемы работы приложения в условиях ОСи.
alekciy
Новичок
Кстати. Приведу пожалуй, дабы не быть голословным, хотя бы одну фразу которая иллюстрирует наличие хаоса в понимании работы системы.
Так у "каждого процесса по одному" или все же "нет ни процессов ни тредов"? В двух предложениях два взаимоисключающих утверждения. Мне вот видится, что это у тебя от того, что ты не понимаешь, как на уровне ОСи запускается приложение и каким образом оно выполняется процессором(-ами). И ты сваливаешь в одну кучу процессоры и процессы.