форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы WEB технологии (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Обсуждение fastCGI ,преимущества-недостатки"
Сообщение от roos (ok) on 03-Июн-05, 12:22  (MSK)
Доброго времени суток всем, столкнулся я с такой проблеммой: движок нашего сайта написан с использованием fcgi. Я с ним никогда раньше не сталкивался-я не программер. Заметил что процессы которые используют fcgi модуль и сам Апач изрядно грузят системму(70% загрузки обоих процов), притом что железо стоит приличное (xeon 2.4 dual), количество хостов около 400(ТЕКУЩАЯ). Понятно что при такой загрузке сайт летать не будет , программеры написавшие движок отнекиваютса мол это нормально, мол железо слабое.   Вот и задумался я что на PHP это могло бы работать намного быстрее и даже на более слабой машине. Я раньше не админил сайт с таким количеством ностов(текущим) и хотел бы узнать ваше мнение. PS: неправильную конфигурацию сервисов я отбрасЫваю- проверено!
	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Обсуждение fastCGI ,преимущества-недостатки"
Сообщение от Денис (??) on 04-Июн-05, 11:36  (MSK)
>и сам Апач изрядно грузят системму(70% загрузки обоих процов), притом что >железо стоит приличное (xeon 2.4 dual), количество хостов около 400(ТЕКУЩАЯ). >Понятно что при такой загрузке сайт летать не будет , программеры написавшие >движок отнекиваютса мол это нормально, мол железо слабое. Для 400 одновременных обращений к скриптам - железо действительно слабое или скрипты неоптимально написаны. Они хоть на каком языке ? >Вот и задумался я что на PHP это могло бы >работать намного быстрее и даже на более слабой машине. Наивный ;-) Ведь сам говоришь что не программист, а берешся судить. >не админил сайт с таким количеством ностов(текущим) и хотел бы узнать >ваше мнение. Что в твоем понимании "хост" ? Число одновременных запросов или число виртуальных хостов которые крутятся на сервере ? Скрипт скрипту рознь, один может просто строчку в файл писать, а другой дулает какие-то вычисления или обращается к СУБД. Второй грузит систему как сотня первых.
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Обсуждение fastCGI ,преимущества-недостатки"
	Сообщение от PoizOn (ok) on 06-Июн-05, 10:49  (MSK)
	>Вот и задумался я что на PHP это могло бы работать намного быстрее и даже на более >слабой машине. Я раньше не админил сайт с таким количеством ностов(текущим) и хотел бы >узнать ваше мнение >Наивный ;-) Ведь сам говоришь что не программист, а берешся судить. PHP сожрет больше ресурсов - хотя может и будет быстрей работать чем FCGI (но это опять же под вопросом). Я бы смотрел в сторону mod_perl, он снимает нагрузку на процессор очень ощутимо - хотя и занимает побольше оперативки.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Обсуждение fastCGI ,преимущества-недостатки"
Сообщение от Solotony on 07-Июн-05, 01:24  (MSK)
>Доброго времени суток всем, столкнулся я с такой проблеммой: >движок нашего сайта написан с использованием fcgi. Я с ним никогда раньше >не сталкивался-я не программер. Заметил что процессы которые используют fcgi модуль >и сам Апач изрядно грузят системму(70% загрузки обоих процов), притом что >железо стоит приличное (xeon 2.4 dual), количество хостов около 400(ТЕКУЩАЯ). >Понятно что при такой загрузке сайт летать не будет , программеры написавшие >движок отнекиваютса мол это нормально, мол железо слабое. >  Вот и задумался я что на PHP это могло бы >работать намного быстрее и даже на более слабой машине. Я раньше >не админил сайт с таким количеством ностов(текущим) и хотел бы узнать >ваше мнение. fastCGI - самое быстрое что можно придумать для веба. это единственное решение, при котором при каждом вызове не стартуется программа и не парсится пользовательский скрипт. т.е управление передается уже откомпилированной изапущенной программе, сидящей в памяти. а что делают-то скрипты? и что такое  "количество хостов около 400(ТЕКУЩАЯ)" - одновременно обрабатывемые запросы?
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Обсуждение fastCGI ,преимущества-недостатки"
	Сообщение от PoizOn (ok) on 07-Июн-05, 09:56  (MSK)
	>fastCGI - самое быстрое что можно придумать для веба. это единственное решение, >при котором при каждом вызове не стартуется программа и не парсится > >пользовательский скрипт. т.е управление передается уже откомпилированной изапущенной >программе, сидящей в памяти. А про mod_perl вы видимо ничего не слышали? Если не слышали - то и тогда тоже не единственное.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Обсуждение fastCGI ,преимущества-недостатки"
	Сообщение от Денис (??) on 08-Июн-05, 23:35  (MSK)
	>А про mod_perl вы видимо ничего не слышали? Если не слышали - >то и тогда тоже не единственное. В mod_perl на каждый процесс апача держится отдельный предкомпилированный образ скрипта. Если у товарища 400 висит процессов и один скрипт, то он будет размножен в 400 экземплярах, и на каждом новом дочернем процессе будет транслироваться заного. FCGI прост до безобразия, скрипт висит в памяти и просто в цикле обрабатывает запросы.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Обсуждение fastCGI ,преимущества-недостатки"
	Сообщение от PoizOn (ok) on 09-Июн-05, 12:31  (MSK)
	>>А про mod_perl вы видимо ничего не слышали? Если не слышали - >>то и тогда тоже не единственное. > >В mod_perl на каждый процесс апача держится отдельный предкомпилированный образ скрипта. >Если у товарища 400 висит процессов и один скрипт, то он будет >размножен в 400 экземплярах, >и на каждом новом дочернем процессе будет транслироваться заного. > >FCGI прост до безобразия, скрипт висит в памяти и просто в цикле >обрабатывает запросы. Ну так апач надо конфигурировать правильно.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Обсуждение fastCGI ,преимущества-недостатки"
	Сообщение от Solotony on 10-Июн-05, 00:05  (MSK)
	>>fastCGI - самое быстрое что можно придумать для веба. это единственное решение, >>при котором при каждом вызове не стартуется программа и не парсится >> >>пользовательский скрипт. т.е управление передается уже откомпилированной изапущенной >программе, сидящей в памяти. >А про mod_perl вы видимо ничего не слышали? Если не слышали - >то и тогда тоже не единственное. Слышали, но как-то не подумали :( Просто привыкли смотреть с точки зрения шаред хостинга, а  там мод-перл неприменим, в отличии от fast-cgi. Ну а если выделенный сервер, то в принципе не должно быть особой разницы. А памяти мод-перл по-всякому больше жрет, поскольку он будет у каждой копии апача (а данные все-таки у каждой копии будут свои), причем неважно, будет она обрабатывать статику, или скрипт. Для особо-загруженных серверов под каждый тип запроса пускают свой веб-сервер, который расчитан на оптимальную обработку именно этих запросов, причем это не обязательно апач. Ну, и естественно надо подумать о кешировании конечных или промежуточных результатов.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Обсуждение fastCGI ,преимущества-недостатки"
	Сообщение от roos (ok) on 01-Июл-05, 16:19  (MSK)
	>>>fastCGI - самое быстрое что можно придумать для веба. это единственное решение, >>>при котором при каждом вызове не стартуется программа и не парсится >>> >>>пользовательский скрипт. т.е управление передается уже откомпилированной изапущенной >программе, сидящей в памяти. >>А про mod_perl вы видимо ничего не слышали? Если не слышали - >>то и тогда тоже не единственное. > >Слышали, но как-то не подумали :( Просто привыкли смотреть с точки зрения >шаред хостинга, а  там мод-перл неприменим, в отличии от fast-cgi. >Ну а если выделенный сервер, то в принципе не должно быть >особой разницы. > >А памяти мод-перл по-всякому больше жрет, поскольку он будет у каждой копии >апача (а данные все-таки у каждой копии будут свои), причем неважно, >будет она обрабатывать статику, или скрипт. > >Для особо-загруженных серверов под каждый тип запроса пускают свой веб-сервер, который расчитан >на оптимальную обработку именно этих запросов, причем это не обязательно апач. > > >Ну, и естественно надо подумать о кешировании конечных или промежуточных результатов. Всем спасибо
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.