PHP vs. C/C++

rst писал:

lega_cobra Несколько замечаний касательно производительности апача + пхп. 1) Советую почитать книги, к примеру "Unix изнутри". Там очень хорошо описано о реализации fork. И тогда Вы избавитесь от заблуждения, что 1000 апачей с пхп (весом 12 метров каждый инстанс) будут жрать 12 гигов памяти. При форканье используется механизм copy on write т.е. пока данные не изменены, они будут занимать память только единожды. А модули не изменяются. Соответсвенно фактически память будет выделенна на все 1000 апачей - только 12 метров + блок окружения для каждого процесса + структуры ядра для каждого процесса.

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

Цитата:

2) касательно опять же производительности. Сейчас один из моих серверов выдерживает 50-100 запросов в секунду. При этом каждый запрос в себя включает : а) работа php скрипта. б) запрос к mysql в) модификация данных в mysql (размер таблицы около миллиона записей) При этом средняя загрузка машины - 10%. Машина - весьма средняя. PIV 1.4 GHz, 1G RAM, IDE HDD. Постоянно крутятся 1000 инстансов апача. Время обработки запроса - 0.8 секунды. Никакого шаманства при настройке и сборке апача не использовалось (кроме компиляции с использованием архитектуры PIV)

До 100 запросов при времени обработки 0.8 - это слишком слабый результат Хотя, зависит от задач действительно. Если не напрягает, то, наверно нормально. Я начал перестройку сервера, когда количество запросов превысило 450 в секунду при среднем времени обслуживания запроса 0.16 секунд. Не статика.

Цитата:

Эх, какой вопрос был - на простой сервак расчитан. А почитаешь топик , так требования, как будто каждый третий лимонами трафа ворочает и десятком личных серверов в стойке, харды коих от свопинга дымятся

прямо в яблочко , что то и вправду увлеклись .

lega_cobra
Что-то мне кажется, что ты хуйню порешь касательо 0.16 секунд. Не буду утверждать, НО мне кажется, что за такое время даже хэндшейк не успеет пройти.

Касательно форков:
Выдержки :
Under Linux, fork is implemented using copy-on-write pages, so the only penalty incurred by fork is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.


Еще насчет Apache и fork() вообще. Как известно в последних версиях Unix(FreeBSD, Linux) fork использяет модель copy on write. Т.е. когда "весящий" 10 Мб в памяти процесс форкается - вся эта облась пямяти ни в коем случае не копируется. Только когда порожденный процесс изменит какие-то данные - скопируются страницы где расположены эти данные и там уже будут произведены изменения.

Ещё вопросы? ;-)

вот кстати немного подсчетов:
размер libphp4.so 1404745 байт
размер httpd 750472 байт
следовательно апач и пхп как минимум занимают 2.155 метра памяти.
у меня запущено 1000 апачей.
(не считая мускуля, который порядка 200 метров кушает из-за буферов).
И ... заюзано 864 метра памяти. своп свободный. Вопрос - почему, если copy-on-write - это миф, то группа процессов которая должна занимать 2 гига памяти (1000 апачей по 2.1 метра) не занимает их?!?!?

Цитата:

Откуда ты знаешь куда мой талант уходит? :-)

А я и не говорю что знаю Но так интересно узнать ...

Цитата:

Я начал перестройку сервера, когда количество запросов превысило 450 в секунду при среднем времени обслуживания запроса 0.16 секунд. Не статика.

так, 450 * 86400 / 2 = 19.440.000 , это будет примерно число запросов в сутки. Если это не статика, то скорее всего вэб страницы.... опа, это где же мы такой траффик то обслуживаем, да и еще на ОДНОМ сервере ?

Кто-то бля начинает завиратсья.
первый момент я уже привел - за 0.16 секунды скорее всего даже ТСР хэндшейк не пройдет. Но это хуйня.
Смотрю статсы по сетке на сервере, у которого 30 запросов в секунду :
2700 открытых или закрывающихся соединений.
Т.е. активировано 2700 тср портов для обслуживания соединений.
Смотрим твой пример : 450 соединений в секунду. Это в 15 раз больше, чем 30 соединений в секунду. Следовательно мы получаем 41000 ТСР портов открытых одновременно. Это нереальное значение для линухового ТСР стека. Ибо 32768 он может стабильно портов держать одновременно.

Кстати. Скажи пожалуйста - какая карточка воткнута в этот сервер? П.с. или ты сейчас съедешь на то, что это кластер?

rst писал:

lega_cobra Что-то мне кажется, что ты хуйню порешь касательо 0.16 секунд. Не буду утверждать, НО мне кажется, что за такое время даже хэндшейк не успеет пройти. Касательно форков: Выдержки : Under Linux, fork is implemented using copy-on-write pages, so the only penalty incurred by fork is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child. Еще насчет Apache и fork() вообще. Как известно в последних версиях Unix(FreeBSD, Linux) fork использяет модель copy on write. Т.е. когда "весящий" 10 Мб в памяти процесс форкается - вся эта облась пямяти ни в коем случае не копируется. Только когда порожденный процесс изменит какие-то данные - скопируются страницы где расположены эти данные и там уже будут произведены изменения. Ещё вопросы? ;-)

Где я вообще что-либо воражал о fork модели линукса? Ты что-то не в ту аргументацию съехал. Я вообще эту ветку рассуждений проигнорил, так-как она относиться к области теоретических рассуждений.

Кстати, логическая ошибка (или не ошибка, а съезд) в твоих рассуждениях заключется в том, что ты предполагаешь достаточно длительное время для апача бех изменения данных после форка. А ведь на практике это не так. Если написать приблуду, которая займет 100 метров под область данных, а потом раплодить ее в 10000 потомков, причем потомки не будут вообще ничего делать, то расход памяти увеличится весьма несущественно. Но ведь это не модель работы апачи.

rst писал:

вот кстати немного подсчетов: размер libphp4.so 1404745 байт размер httpd 750472 байт следовательно апач и пхп как минимум занимают 2.155 метра памяти. у меня запущено 1000 апачей. (не считая мускуля, который порядка 200 метров кушает из-за буферов). И ... заюзано 864 метра памяти. своп свободный. Вопрос - почему, если copy-on-write - это миф, то группа процессов которая должна занимать 2 гига памяти (1000 апачей по 2.1 метра) не занимает их?!?!?

Что-то тебя занесло out of topic. Скажи честно, это у тебя прием такой - вложить в чужие уста ложное предположение, а потом с боем их опровергать? Я расчитываю, что это просто результат небольшой путаницы с твоей стороны, не более того. Изначально я говорил исключительно о контексте задачи. Я сильно подозреваю, что твои 1000 апачей сервят скорее всего один сайт с довольно-таки небольшим объемом данных. Сколько у тебя занимает активная часть webroot?

Кстати, покажи grep Vm /proc/????/status какого-либо потомка.

Кстати, для прикола:
-rwxr-xr-x 1 root root 310420 Oct 23 06:55 httpd
-rwxr-xr-x 1 root root 2153844 Oct 21 09:56 libphp4.so

Апач 2.0.47 - пересобранный с изменением некоторых defines.
PHP 4.3.3 сандартной компиляции (я его не гружу).

Чего такой httpd большой? Посмотрел на нескольких серверах у коллег - нигде размер httpd не превышает 320 кил, что по первой, что по второй версии.

Думаю преимуществом PHP является то, что не нужно помещать скрипты в определённую папку (cgi-bin). Полная интеграция со страницами.

rst писал:

Кто-то бля начинает завиратсья. первый момент я уже привел - за 0.16 секунды скорее всего даже ТСР хэндшейк не пройдет. Но это хуйня.

Нет, это не хуйня. Расскажи мне, плиз, как это у тебя apache занимает TCP хендшейами? Ими занимается стек, однако. И к обсуждаемой проблеме форков (блин, мы уже, оказывается, обсуждаем эту проблему, надо же) - не относится.

Цитата:

Смотрю статсы по сетке на сервере, у которого 30 запросов в секунду : 2700 открытых или закрывающихся соединений. Т.е. активировано 2700 тср портов для обслуживания соединений. Смотрим твой пример : 450 соединений в секунду. Это в 15 раз больше, чем 30 соединений в секунду. Следовательно мы получаем 41000 ТСР портов открытых одновременно. Это нереальное значение для линухового ТСР стека. Ибо 32768 он может стабильно портов держать одновременно.

Подсчеты в стиле "100 тысяч зрителей по одному рублю"....
Во первых твои расчеты некорректны, так-как основаны изначально на некорректных данных. Я же не пытаюсь расчитывать нагрузки сервера, ставя бенчмарки на домашнем сервере

Во вторых - проблема ухода сокетов действительно серъезная (кстати, и не только в линуксе). Из-за этой проблемы я в 98 году разругался в АстраЛабом, послал их нафиг, и с того момента больше никогда не пользовался услугами стороннего админа. Облом наступил при достижении отметки в 200 запросов в секунду.

Решений данной проблемы тоже немерянное количество, начиная от изменения настроек стека через /proc/sys/net/ipv4/, а так же перекомпиливания ядра с изменением системных дефайнов, и до прямого патча стека, как такового. Самый первый шаг - борьба с сокетами-сиротами (практически для любого юникса рецепты есть). В большиснтве случаев, этого достаточно, что бы повысить производительность стека до необходимой величины. Замечу, что инфы по поводу чистки стека в интернете не просто много, а валом. Если есть желание развить диспут в этом направлении, обсуждая достоинства или недостатки тех или иных методов - то попозже. К сожалению, работа заваливает нафик.

Цитата:

Кстати. Скажи пожалуйста - какая карточка воткнута в этот сервер? П.с. или ты сейчас съедешь на то, что это кластер?

В какой именно? Например в те сервера, о которых я говорил, воткнуто по 4 штуки внешних 100 мегабитных карт (внутреннюю сетку я не считаю). Если интересуют модели - посмотрю потом. Каждый конец воткнут в nationalnet-овские бекбоновые свичи. Конфигурация действительно несколько нетипичная, так-как принято считать, что обычный линух не загрузит даже одной карточки (странно, почему такое мнение существует). Просто пришлось поработать "напильником" на всех уровнях, начиная с ядра. Но затея стоила того, ибо рассплитовка серверов или, как ты заметил, установка кластера при таких (относительно) мизерных задачах - не лучшее решение.

P.S. Вопрос на засыпку - почему в 99% случаев народ относится к OS customizing с такой священной дрожю? Почему поставив сервер под свои задачи, каждый старается натянуть на него пренепременно "стандартную упаковку"? Почему даже в этой ветке многие подбирают аргументы так, как будто кто-то насильно навязывает значения по умолчанию? В чем проблема? Почему, если я сказал, что web-приложение лучше написать на C - все начали наезжать на меня, примеряя мое мнение не к моим задачам, а к своим, которые им приходится решать в навязанных условиях? И последний вопрос, кто бы отказался от CJ, написанного в виде молуля?

clever писал:

Думаю преимуществом PHP является то, что не нужно помещать скрипты в определённую папку (cgi-bin).

Кстати, cgi тоже не обязательно помещать туда. Они могут лежать где угодно и называться как угодно

Цитата:

Полная интеграция со страницами.

Давай заметим так - "готовая интеграция". Действительно, другие языки в голом виде такой интеграции не имеют. Но кто пишет на голом инструменте? У меня есть наработки, позволяющие создавать разные уровни интеграции в шаблонно-парсерные приложения. Они оптимизированны под С/C++ и хорошо встраиваются как в обычные cgi, так и в модули апачи. Наработки даю только своим программерам, больше никому.

Цитата:

P.S. Вопрос на засыпку - почему в 99% случаев народ относится к OS customizing с такой священной дрожю? Почему поставив сервер под свои задачи, каждый старается натянуть на него пренепременно "стандартную упаковку"? Почему даже в этой ветке многие подбирают аргументы так, как будто кто-то насильно навязывает значения по умолчанию? В чем проблема? Почему, если я сказал, что web-приложение лучше написать на C - все начали наезжать на меня, примеряя мое мнение не к моим задачам, а к своим, которые им приходится решать в навязанных условиях? И последний вопрос, кто бы отказался от CJ, написанного в виде молуля?

Я тебе поясню.
Во-первых это стандарт на сравнения. Во вторых -в своей ситуации я не вижу необходимости никаких наворотов. В третьих - Я не отношусь к OS Customizing со священной дрожью. Я даже всячески приветствую его.

Касательно хендшейков:
обработка запроса сводится к следующему:
1) создание TCP Соединения. (т.е handshake)
2) отсылка броузером запроса серверу.
3) Обработка запроса сервером.
4) Отсылка результатов клиентом.
Т.е.т фактически время обработки запроса это время, которое отделяет нажатие клиентом на ссылку, и получение результатов на экране.
И Вы говорите, что это 0.16 секунд? Херня, не верю ( (c) Full Metal Jacket)

rst писал:

Я тебе поясню. Во-первых это стандарт на сравнения. Во вторых -в своей ситуации я не вижу необходимости никаких наворотов. В третьих - Я не отношусь к OS Customizing со священной дрожью. Я даже всячески приветствую его. Касательно хендшейков: обработка запроса сводится к следующему: 1) создание TCP Соединения. (т.е handshake) 2) отсылка броузером запроса серверу. 3) Обработка запроса сервером. 4) Отсылка результатов клиентом.

Я уже устал от этой дискусии. Херня - это говорить сначала, что 1000 апачей знаимают 12 метров памяти + еще что-то (тебя цитировать?), потом почитать что-то, прилепить в спор модель форка, которая пытается втиснуть твои теоретические апачи в 12 метров, и потом вдруг выяснить, что несмотря на прилепленную не к месту модель форка, реально эти 1000 апачей занимают более 800 метров. А я так и не понял, как модель форка противоречит проблеме серъезного расхода памяти в интерпретирующих системах (ну разве что все 1000 процессов пожизненно интерпретируют одну и ту же строку ) А без этого какой смысл было о ней вспоминать? Ну и потом для усугубления "поражения оппонента", вложить в его уста утвердение о мифе этой модели.

ОК! Можно нескольк вопросов?

1) Почему у тебя постоянно болтается 1000 копий апачи? Ты их всех запускаешь в стейбл? А что это дает?

2) Есть ли различие между "временем обслуживания" и "временем обработки запроса"? И заодно, от чего зависит время TCP handshakes?

3) Ты так и не сказал, каков объем контента обслуживает твой сервер.

Цитата:

Т.е.т фактически время обработки запроса это время, которое отделяет нажатие клиентом на ссылку, и получение результатов на экране. И Вы говорите, что это 0.16 секунд? Херня, не верю ( (c) Full Metal Jacket)

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

Есть желание написать больше вопросов, но нет времени. Так-что я удаляюсь из этого топика по причине его абсолютной неконструктивности. С преподаванием TCP технологий я закончил лет 15 назад - неблагодарная работа. Если будет что-либо конструктивное - я с удовольствием поучаствую. А сейчас, пардон, у меня своих дел много.

P.S. Кстати, я как-то даже не подозревал раньше, что HTML, или, там, shell scripting - языки програмиррования Они-то языки, только вот чего?

P.S.S. Что-то мне этот спор напоминает что-то из народной классики, типа "... ложечку-то мы нашли под столом, но неприятный осадок остался..." Извините, удаляюсь.

1) Касательно копий апача. А так же времени обслуживания запроса.
1К апачей болтается для того, чтоб не тратить время на форки. Т.к. При запросе вначале происходит коннект с демоном, потом тот порождает потомка для обслуживания запроса, и передает ему сокет.
Посему чтоб не тратить время на форк - запущено постоянно 1К апачей. Помимо этого каждый апач живет - 5 запросов макс. Т.к. если апачу дать жить больше, то он не будет так уж стабильно работать. А 5 запросов - достаточно приличный trade-of между производительностью системы и нагрузкой.
2) касательно хендшейков. Это есть неотъемлимая часть сессии. И я приводил пример - 0.8 секунд именно "от начала" и "до конца".
3) Это не платник. Там практически только скрипты и текст, но большой объем траффика.

Цитата:

P.S. Кстати, я как-то даже не подозревал раньше, что HTML, или, там, shell scripting - языки програмиррования Они-то языки, только вот чего?

Вижу аргументы кончились, и разговор перешел в треп, и попытки унизить оппонента, и придраться к его словам. Так что дальнейшая дискуссия по этой теме идет на*уй.

rst писал:

1) Касательно копий апача. А так же времени обслуживания запроса. 1К апачей болтается для того, чтоб не тратить время на форки. Т.к. При запросе вначале происходит коннект с демоном, потом тот порождает потомка для обслуживания запроса, и передает ему сокет.

Что-то мне подсказывает, что апач работает немного не так. Он всегда держит в "запасе" несколько idle потомков, что бы передавать ему поступившие запросы.

Цитата:

Посему чтоб не тратить время на форк - запущено постоянно 1К апачей.

А на форк время тратится только в том случае, если происходит взрывное возрастание потока запросов, например, при дос атаках. При этом, апач не будет по принятому запросу рождать потомка. Если к взравному трафику не окажется "запасных" потомков (или они будут еще не готовы обслуживать запросы), апач откажет в обслуживании по этому конкретному запросу.
Все случаи отказа обслуживания можно посмотреть в сырцах апачи. Код там достаточно опрятный и понятный, так-что читается легко.

Цитата:

Помимо этого каждый апач живет - 5 запросов макс. Т.к. если апачу дать жить больше, то он не будет так уж стабильно работать. А 5 запросов - достаточно приличный trade-of между производительностью системы и нагрузкой.

Ну этот параметр каждый выбирает для себя сам

Цитата:

2) касательно хендшейков. Это есть неотъемлимая часть сессии. И я приводил пример - 0.8 секунд именно "от начала" и "до конца".

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

Так-что либо ты в этот критерий вкладываешь какие-то параметры, про которые я не понял. Либо что-то перепутал. Такое бывает

Реально, создание сокета в стеке происходит на порядки быстрее, чем даже открытие локального файла.

Цитата:

3) Это не платник. Там практически только скрипты и текст, но большой объем траффика.

Тогда понятно, почему контекст каждого потомка занимает чуть меньше 1 метра. Затраты памяти в апаче составляют в основном обработка контента (чтение в память, обработка-интерпретация, отдача). Если контент имеет органиченный размер и структуру, то контекст раздуваться не будет.

Цитата:

Вижу аргументы кончились, и разговор перешел в треп, и попытки унизить оппонента, и придраться к его словам. Так что дальнейшая дискуссия по этой теме идет на*уй.

Странно, это было лишь мое мнение, что я считаю языками программирования, а что не считаю. Каждый волен считать так, как он хочет. Унижением может быть утверждение, что ты какие-то языки из списка не знаешь (этого не было ведь?), или приписываение оппоненту слов, которые он не говорил, типа "ты не прав, утверждая что модель форка - это миф" (я же такого никому не приписывал, не так ли?).

Так-что если ты расценил мое замечание, как попытку унизить, и этим закончить дискуссию, это твое право. Раз так, значит так.