PHP to C

[Stek]

ИМХО держать открытым одно соединение легче(для сервера), чем постояно открывать новые.

Теоретически да, а на практике это совершенно по другому. Когда из за мелкого пика колличество коннекшенов подскакивает до 20-30 , а потом так и остается висеть в памяти, и так для нескольких проектов - то рано или поздно один вызов ps ax приводит сисадмина в ужас.
И на практике, при использовании pconnect гораздо чаще появляется ошибка "too many connection", да и ресурсы жрутся побольше.

 

[Tronyх]

что значит ИМХО?

по моему скромному мнению, или что-то вроде.

А что, оно будет ОДНО на ВСЕ активации скрипта? Что-то мне сомнительно...

А почему бы и нет? Можно написать демона который и будет этим заведовать.

 

[AnToXa]

В если проект будет нагруженный, то пконнект просто убъет вам или базу, или сам сервер, смотря как будут ресурсы распределенны

бля. я говорю не про пхпшный mysql_pconnect !
а про то, чтобы держать коннекты в SRM! там простой mysql_connect! и Ускорится это все очень даже хорошо... si - ты неправ
я не делал тестов в пхп, но по субъективным ощущениям с постоянным коннектом все гораздо быстрее.

 

[Stek]

SRM - это что ? шаред мемори ?

 

[AnToXa]

это спросить у тони.
tony2001.narod.ru

 

[Tronyх]

Теоретически да, а на практике это совершенно по другому. Когда из за мелкого пика колличество коннекшенов подскакивает до 20-30 , а потом так и остается висеть в памяти, и так для нескольких проектов - то рано или поздно один вызов ps ax приводит сисадмина в ужас.
И на практике, при использовании pconnect гораздо чаще появляется ошибка "too many connection", да и ресурсы жрутся побольше.

Никто не говорил про pconnect.

 

[camel]

1.Т.е. если не актуальны сессии майскл(т.е. не используються TEMPRARY TABLEs), то типа держать один коннект, вопрос в том как получить доступ, к хендлеру, этого коннекта....
2.Где монна надыбать доку по сему или ваще какую нить инфу?
3.Если шаред мемори то как это красивее организовать?
4. И еще вопрос C + FastCGI будет ли быстрее пХп встроенного в апач как модуль?

 

[AnToXa]

это все пишется применительно к c + fastcgi
1. как вариант - shared memory
2. хммм.... попробуй httpd.apache.org -> search -> mod_fastcgi
если есть более конкретные вопросы - задавай.
3. выделить кусок памяти, в него записать структуру MYSQL, и делать что-то вроде этого

тут shmget ... с sizeof(MYSQL)
MYSQL *mysql = (MYSQL *)shmat (id, 0, 0);
mysql_connect (mysql, тырым-пырым....);

4. хм. думаю да, но надо бы почитать мануал на mod_fastcgi. пойду-ка и я образовываться

 

[tony2001]

>SRM - это что ? шаред мемори ?
http://detail.phpclub.net/2002-05-26.htm
http://www.vl-srm.net
http://tony2001.narod.ru/srmdoc/

 

[netdog]

Болванка у тебя уже есть -- это сам PHP. Просто почитай его исходники.

Млин, А действительно
Как-то тоже искал...

 

[leosha]

clevel - покажи пример своего кода на PHP. Небольшой хотя бы фрагмент.

 

[clevel]

clevel - покажи пример своего кода на PHP. Небольшой хотя бы фрагмент.

что тебя именно интересует?

 

[leosha]

У тебя код стартовой страницы выполняется 2 секунды?
Мне интересно ЧТО ИМЕННО может выполнятся 2 сек.
Понятно дело, не рассматриваем специфические скрипты, которые запускаешь ты один и то ручками и раз в неделю.
Вот ты говорил что мерил скорость. Что там так долго выполняется у тебя?

 

[clevel]

да не стартовая страничка...
например, у меня есть модуль типа "Эксель он-лайн"... там много выборок из БД, парсинг формул... вот это и замедляет работу....

 

[Yurik]

там много выборок из БД

извините что вмешиваюсь, но кто из вас даёт гарантию что программа написанная на Си которая интенисвно работает с сервером БД (например МуСкул) будет ощутимо быстрее (не в пять а хотя бы в полтора раза)
Время на соединение и выборку определяется Субд, а время работы собс-но Си или Пхп или ещё чего ничтожно мало.

Да, и где гарантия того что простую конструкцию типа
echo $_SESSION['var']
вы напишите на Си лучше чем это сделали пхп разработчики (тоже на Си) за много лет

 

[clevel]

в чем грабли... у меня не просто идет куча выборок из бд, а сначала берется формула из БД, далее парсится(пхп), определяются запросы к бд(пхп) и далее делаем запрос(мускул), обрабатываем результаты(пхп)....
немного оптимизировал пхп скрипты, скорость увеличилась в два раза!!!!!!!
если учесть, что в пхп тормозят многомерные массивы(даже двухмерные, а мне без них ну никак), ассоциативные массивы, парсер медленнее чем один раз скомпиленный бинарник... так что вот...
хотя пока решил оставить все на пхп - неохота мегабайт кода переводить на си.... у меня много модулей помимо движка... так что пока не время...

 

[tony2001]

>немного оптимизировал пхп скрипты, скорость увеличилась в два раза!!!!!!!
тогда может стоит оптимизировать дальше, раз у вас такие проблемы с кодом?

 

[.des.]

clevel твоя проблема в том.. что ты делаешь в пхп работу мускла.. не надо этого делать. Наверняка ты делаешь мегабайтные выборки из бд.. и работаешь с ней в пхп в многомерных массивах.. странно как это вообще выполняется.

 

[leosha]

Вот и мне кажется, что такой тормозной скрипт можно по любому оптимизировать.
А если речь идет о МЕГАБАЙТАХ кода, то разговор о переводе на Си вообще несерьезно выглядит как-то. проще уж теперь тупо увеличивать мощность сервера(серверов), приделывать всякие акселлераторы и т.д.
Не, ну понятно что первым делом нужно попытаться оптимизировать скрипты свои.. =)

 

[aloner]

1. Портани базу на pgsql/oracle и сделай обработку формул на встроенном языке (plpgsql/plperl/plsql/java etc...).

Из собственного опыта могу посоветовать такую схему:
-- Сами формулы, как я понимаю, написаны в неком псевдокоде, вот его нужно пропарсить и собрать в "родной" базе код (plsql/plpgsql, т.е. заточенный на работу с данными), который будет вызывать эмулированные (на "родном" языке) функции - для скорости.
-- Парсинг лучше всего делать на "взрослом" языке (java/plperl). А затем уже тот код выполнять на "родном". Так быстрее всего.

...или 2. Для mysql можно попробовать написать udf-функций на C.
Хотя имхо гораздо удобнее делать это на встроенном языке СУБД.

Не стоит делать в PHP работу СУБД - слишком много расходов на траффик в базу. К тому же PHP - не лучший инструмент для быстрого перемалывания больших объемов данных.

Не так давно писал эмуляцию рассчитываемых полей от CTD для Оракла на PLSQL/Java (нужно было от CTD отвязаться и просто сделать процесс расчета менее ресурсоемким). Стало на порядок быстрее работать.