- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Естественно, автор такого теста некомпетентен :)
А вот автор исходного теста писал не только про fastcgi - осмысленность которого сомнительна без тестов, а про ускорение при уменьшении количества исходных файлов, которые читает eAccelerator, именно это самое интересное в тесте. Получается, что простое кэширование на стороне eA должно дать 2000 процентов производительности.
Я про файлы и не спорю. А привел результаты своего апгрейда. Тестом это действительно назвать нельзя, т.к. не соблюдены условия тестирования (напп. одинаковые версии софта). Тем не менее даже навскидку мой результат не совпадает вот с этим выводом:
Да, в теории, если сравнивать apache+mod_php+eacc и apache+fastcgi+eacc то может быть эта фраза несла бы какую то пользу, однако php с FastCGI запускают не из любви к искусству (читай не из любви к супер-технологии FastCGI ), а для того чтобы использовать легкий фронтенд. Получается, толку от статьи (кроме исследования влияния объединения файлов в include ) ноль :)
См. у другого человека похожие на мои результаты.
http://forum.dklab.ru/viewtopic.php?p=157355#157355
Попробуйте провести чистый тест на сервере, где нет рабочих проектов. Правда на самом деле спор неочем.
Связка nginx+apache+eaccelerator есно будет уступать fastcgi на рабочем сервере, т.к. апач ведь всё-равно вызывается и хавает память. Причем если загружено много модулей - то хавает просто оочень много памяти.. Пусть и на короткое время.
Поэтому нужно понимать, что если не ограничить кол-во процессов апача отталкиваясь от свободной оперативной памяти на сервере - то при всплеске нагрузки (тот же тест допустим) серверу будет плоха
По поводу коммента на форуме dklab: делать тест на сервере с рабочими проектами под нагрузкой, это вообще извините меня что-то нецензурное. Ещё нецензурнее потом полученные результаты выкладывать в паблик
Лично у меня пока не было необходимости переходить на fastcgi. Но я не отрицаю, что она есть у тех у кого нет возможности поставить себе дополнительную память на сервер
И наконец, а ничего, что Яху на ПХП писан?
Ну тут вы немного загнули. У них там отображение работает на пхп, а вот вычисления я думаю нет :) Как бы мне лично не нравился пхп...
А по поводу Котерова, то видя как тормозит (или по крайней мере тормозил ранее) МойКруг его советов по оптимизации не хочется слушать :) Хотя, как автор самоучителя по пхп, его никто, имхо не превзошёл.
А по поводу Котерова, то видя как тормозит (или по крайней мере тормозил ранее) МойКруг его советов по оптимизации не хочется слушать :) Хотя, как автор самоучителя по пхп, его никто, имхо не превзошёл.
как велосипедиста его никто не превзошёл :)
Pilat добавил 08.08.2008 в 16:22
Пока php не научится убирать за собой после запросов - никакой fastcgi ему не поможет, ИМХО.
Попробуйте провести чистый тест на сервере, где нет рабочих проектов. Правда на самом деле спор неочем.
Пока, к сожалению, не до этого... В любом случае, тесты проводились в разное время много раз (и даже глубокой ночью), при разной паразитной нагрузке ( она очень низкая в любом случае, сервер реально простаивает). Я же не зря написал диапазоны полученных результатов, как раз разброс типа 35-37 и 60-70 и вызван паразитной нагрузкой, искажающей результаты тестов. Запущенные процессы я видел, боты сервер не насиловали...Своп системой не использовался (памяти 1гб хватало)
По поводу коммента на форуме dklab: делать тест на сервере с рабочими проектами под нагрузкой, это вообще извините меня что-то нецензурное. Ещё нецензурнее потом полученные результаты выкладывать в паблик
К сожалению, отдельного сервака нет под рукой...Про свои тесты отвечу, как уже сказал, проверялось при нулевой нагрузке и несколько раз в разное время суток.
Лично у меня пока не было необходимости переходить на fastcgi. Но я не отрицаю, что она есть у тех у кого нет возможности поставить себе дополнительную память на сервер
Лишней памяти не бывает, даже если вы свой сервер под завязку набьете, все равно имеет смысл оптимизировать и освобожденные ресурсы системы пустить на что-нибудь полезное. Вот взять задачи с которыми я работаю - Drupal, там можно очень много всего, memcached, APC memory cache, MySQL query cache, файловый кеш, и под все нужна память, чем больше тем лучше.
Да, мои проекты щас далеки от 70 и даже от 20 запросов в секунду, зато я спокойнее живу, зная, что мой сервер выдержит гораздо большую пиковую нагрузку (например, т.н. Digg-effect ) чем раньше
Ну тут вы немного загнули. У них там отображение работает на пхп, а вот вычисления я думаю нет :) Как бы мне лично не нравился пхп...
Хех... Ну я ж о чём... Под каждую задачу - свой инструмент. :)
Лично мне глубоко фиолетово, на ПХП сайт делать или на С++. Если задача позволяет сделать быстро и с достаточным качеством реализовать её на ПХП, то лично мне совершенно всё равно, если кто-то считает ПХП не кошерным. :) Если в рамках этой задачи есть _маленькая_ подзадача, скажем, отдача информеров для высоконагруженных сайтов со сбором статистики, то она делается на Си + кеширование в файлах или мемкеше и скрипт на 1,5 килобайта _естественно_ рвёт по производительности всё что можно. При этом мы получаем разумный баланс между удобством саппорта сайты на ПХП и производительностью подсистем, где эта производительность реально востребована.
Santyago
А если добавить сюда, что хороших, открытых и бесплатных CMS/CMF на Си не наблюдается, а все больше на скриптовых языках, получим ,что проще (и выгоднее) для большинства проектов взять готовое решение и доработать под свои нужды, а рассуждения, что лучше, оставить теоретикам-программистам ( типа анонимусов на ЛОРе, которые устраивают холиварс какой язык круче) и очень большим компаниям, которые могут себе позволить держать свой штат программистов и разрабатывать весь функционал с нуля на том языке, который больше подходит для задачи ;)
Santyago
А если добавить сюда, что хороших, открытых и бесплатных CMS/CMF на Си не наблюдается, а все больше на скриптовых языках, получим ,что проще (и выгоднее) для большинства проектов взять готовое решение и доработать под свои нужды, а рассуждения, что лучше, оставить теоретикам-программистам ( типа анонимусов на ЛОРе, которые устраивают холиварс какой язык круче) и очень большим компаниям, которые могут себе позволить держать свой штат программистов и разрабатывать весь функционал с нуля на том языке, который больше подходит для задачи ;)
О! Полностью согласен! :)
Раз уж пошла такая пьянка, никто не знает как решить проблему потребления памяти в разросшихся движках http://groups.google.com/group/highload-php-ru/browse_thread/thread/53a1be8c49ae827d/f645e7764e5bc517 ?
(если внимательно читать, там написано почему memcached не выход)
Memcached - выход, если в него помещать предгенеренную страницу и отдавать nginx