оффтоп из «php программист»

[varan]

Почему баннерная крутилка и на ПХП ?

У нас тоже на php, почему нет

 

[cDLEON]

У нас тоже на php, почему нет

Да я как бы не против! Просто интересно зачем "жрать кактус" в случае с системой, где в пиках >1000 insert'oв в секунду...

 

[флоппик]

Да я как бы не против! Просто интересно зачем "жрать кактус" в случае с системой, где в пиках >1000 insert'oв в секунду...

Открою страшную тайну — инсерты все равно в базе исполняются.

 

[Mols]

Вообще вопрос "почему на PHP" мне тоже интересен. (правда может в отдельную бы ветку его?)
Как только возникает необходимость юзать мемкеш и акслераторы, то сразу хочется что нить типа JAVA.
Где есть общая для запросов память и код компилится не при каждом запуске.
Опять же нет проблем с синхронизацией доступа....
Да и средств для мониторинга побольше.
В общем действительно интересно почему пых?
Потому, что лучше всего знали когда начинали?
Или таки был процесс разносторонней оценки технологий?

 

[alekciy]

Найти на проект PHP разработчика требуемого уровня проще, чем на Java. Плюс, понятное дело, что если на данном ресурсе авторы проектов по бОльшей свой части PHP-шники, то и стартовая платформа это PHP. При таком раскладе глупо базироваться на новой платформе если хорошо знаешь старую. А дьявол всегда кроется в деталях. Поэтому если нет объективных причин и явных профитов от перехода на новую платформу, то и переходить нет смысла. А все изложенные проблемы в PHP и так имеют тот или иной вариант решения.

Мне вот для одного проекта очень хотелось заюзать Erlang тем паче что сейчас на нем даже готовая CMS есть. Но после всесторонней оценки решил, что основное ядро будет все же PHP-шное. А на Erlang-е будут некоторые подсистемы.

Кроме того в случае чего всегда можно вынести критичные к скорости куски кода в С-шный экстеншен. В общем по ходу дела становиться видно на реальной задаче что нужно крутить и где. В настоящее время путь развития веб приложение - эволюционный, другого более адекватного подхода лично я не знаю.

 

[varan]

Как только возникает необходимость юзать мемкеш и акслераторы, то сразу хочется что нить типа JAVA.
Где есть общая для запросов память и код компилится не при каждом запуске.

Мемкеш может лежать на отдельных серверах вообще без php и java, если это выгодно.
Компиляция кода - это вообще не проблема. apc и всё такое.

 

[fixxxer]

В хайлоаде выбор языка это вообще стопицотый вопрос. Упирается все совершенно в другие вещи.

 

[cDLEON]

Открою страшную тайну — инсерты все равно в базе исполняются.

Дело не в количестве инсертов. Дело в том, что используя что-нибудь вроде Java/Python можно сократить работу с базой в разы, убрать оверхеад от создания процесса на запрос и более просто и дешево масштабироваться....

 

[alekciy]

Дело не в количестве инсертов. Дело в том, что используя что-нибудь вроде Java/Python можно сократить работу с базой в разы, убрать оверхеад от создания процесса на запрос и более просто и дешево масштабироваться....

Ну так в чем проблема? Нравиться, делаем на Java/Python/etc.

P.S. Имхо, в реальном веб приложении всё все равно упрется в бизнес логику самого приложения, а не платформы.

 

[fixxxer]

Дело не в количестве инсертов. Дело в том, что используя что-нибудь вроде Java/Python можно сократить работу с базой в разы

Это как это?

убрать оверхеад от создания процесса на запрос

С акселератором он минимален. При особом желании есть решения типа phpDaemon (которые кстати даже шустрее будут чем питоновские аналоги ибо libevent).

и более просто и дешево масштабироваться....

Попа-дробнее?

 

[varan]

начали с вакансии, а закончили "php против java"

 

[~WR~]

Так и есть: раздел "Работа" - самый содержательный на этом форуме.

 

[cDLEON]

Это как это?

За счёт хранения промежуточных состояний прямо в памяти процесса без огородов мемкеша.

С акселератором он минимален. При особом желании есть решения типа phpDaemon (которые кстати даже шустрее будут чем питоновские аналоги ибо libevent).

Что значит минимален ? Создание форка\потока само по себе приличный оверхед. Да и в питоновских аналогах этот самый либевент тоже поддерживается. А вот память течь по-меньше будет....

Попа-дробнее?

Ну в случае с ПХП обязательно нужно городить огороды мемкешей, выдумывать системы репликаций, в случае с кучей управляемых одно-поточных демонов всё это можно забыть как страшный сон.

 

[fixxxer]

То есть для тебя хайлоад заканчивается на системах, помещающихся на один сервер. Понятно.

 

[cDLEON]

То есть для тебя хайлоад заканчивается на системах, помещающихся на один сервер. Понятно.

Обажаю ПХПклаб Чуть что так сразу начинают давить "авторитетом" )))
Ну в каком месте, скажите в каком месте, я говорил об одном сервере ? Неужели данную модель нельзя положить за балансировщик ?

 

[fixxxer]

За счёт хранения промежуточных состояний прямо в памяти процесса без огородов мемкеша.

Вот здесь.

Ну в случае с ПХП обязательно нужно городить огороды мемкешей, выдумывать системы репликаций, в случае с кучей управляемых одно-поточных демонов всё это можно забыть как страшный сон.

И вот здесь.

Я бы еще понял, если бы речь шла об erlang (и тут бы даже согласился). Но причем тут петоны с джавами?

 

[флоппик]

Особенно, причем тут питон с его GIL-ом на многопроцессорных системах, ага.

 

[cDLEON]

Особенно, причем тут питон с его GIL-ом на многопроцессорных системах, ага.

Я же говорю о скриптах-однопоточниках !!!! При чём здесь ГИЛ вообще????

 

[флоппик]

При том, что он очевидно будет использовать лишь одно ядро.

 

[cDLEON]

При том, что он очевидно будет использовать лишь одно ядро.

Но он, в случае с задачей вроде "баннерной системы", будет работать в разы быстрее, имхо. И уж если упрётся в процессор, ни кто не мешает запустить в несколько процессов, например, так: http://docs.python.org/library/multiprocessing.html