использование рнр в блоках замедляет работу сайта? Просто у меня на главной странице - 4 блока построеных на рнр (сниппеты). Я использую их для выдачи различных типов последних материалов.
Но я считал, что таким образом нагрузка на сервер будет меньше, чем при использовании views....
А ещё не использовать PHP в блоках и страницах.
И как финальная стадия, перейти на FastCGI»
FastCGI для Php не дает прироста. Об этом свидетельствует статья оч. уважаемого человека Дмитрия Котерова. http://dklab.ru/chicken/nablas/49.html ... Хотя об этом выше написали уже)
Нашел инструкцию по установке APC на хостинге nic.ru, поставил, время выполнения php сократилось в 3-4 раза.
Не знал что время Page execution time was 3512.58 ms. которое показывает Devel зависит от скорости канала.
На 128kB/s - Page execution time was 2025.61 ms.
На 512kB/s - Page execution time was 597.35 ms.
Смотрим на инструкцию по установке:
$ gunzip -c apc_x.y.tar.gz | tar xf -
$ cd apc_x.y
$ /usr/local/php/bin/phpize
$ ./configure --enable-apc --enable-apc-mmap --with-apxs --with-php-config=/usr/local/php/bin/php-config
$ make
$ make install
И делаем почти тоже самое:
/usr/opt/php5/bin/phpize
./configure --enable-apc --enable-apc-mmap --with-php-config=/usr/opt/php5/bin/php-config
make
make test
далее в папке modules имеем файл apc.so
создаем папку php_extensions и копируем туда apc.so и все php extensions из /.ro/usr/opt/php5/lib/php/extensions
копируем php5.ini в свой каталог (там уже лежит файл .my.cnf)
переименовываем его в php.ini
и редактируем
Код:
<?php register_globals=0 allow_url_fopen=1 max_input_time=60 max_execution_time=30 safe_mode=0 error_reporting=2039 session.save_path=/tmp allow_url_include=0 file_uploads=1 magic_quotes_gpc=1 default_charset= default_socket_timeout=120 memory_limit=48M post_max_size=10M upload_max_filesize=10M #extension_dir="/opt/php/lib/php/extensions/" extension_dir="/home/ИМЯ_ЮЗЕРА/php_extensions/"
extension=zlib.so extension=xml.so extension=iconv.so extension=curl.so extension=gd.so extension=zip.so extension=mbstring.so extension=mysql.so extension=apc.so .my.cnf Код: mysql.default_host=ИМЯ_ЮЗЕРА.mysql mysql.default_port=3306 default_character_set = utf8 перезапускаем апач (для этого есть синяя иконка в админ панели хостинга, но помоему можно и в SSH перезапустить)
создаем файл с <?phpinfo();?> и проверяем что нам показывает - там будет секция с apc
как посмотреть расход памяти: копируем файл apc.php из дистрибува, переименовываем его, вбиваем в нем логин\пароль
Если кто желает спонсировать развитие этого мануала, то вот партнерская ссылка (nic.ru платит партнерам процент от платежей приведенных ими клиентов). Замечу, что о nic.ru только у меня сложилось хорошее впечатление. Ставлю туда уже 3-его клиента.?>
надо бы попробовать! у меня там тоже сайт. хостинг устраивает по всем техническим параметрам (скорость, память и т.д.), но вот техподдержка - мягко говоря, оставляет желать лучшего. на некоторые мои вопросы ответа так и не получил, сам разбирался.
block chache ставил. В настройках модуля поставил enable.
Но почему то не все блоки можно кешировать... и те которые нужно не кешеруются. заходишь в настройки блока, а там о block chache ни слова. А те которые не нужно кешируются и в найстроках блока можно выбирать...
Почему так?
А ещё не использовать PHP в блоках и страницах.
И как финальная стадия, перейти на FastCGI
дело говорит. Тока сначало надо патч на php для FastCGI поставить. PHP залетает. Отвечаю. Тока незнаю как потом с этим делом APC заюзать вместе. Знаю как на eAccelerator.
у меня на хостинге в настройках сервера есть этот FastCGI
можно галочку поставить - чтобы включить
Вопрос - это то или нет, в смысле будет у меня ускорение или нет?
Нашел объяснение ускорению работы сайта и уменьшение потребляемой памяти при включении сжатия страниц gzip.
Как ни странно нашел это в тестовой установке битрикса
Почему умирают сайты?
Оперативная память: медленные каналы
Еще один аспект проблемы – это медленные каналы пользователей вашего сайта по меркам веб-сервера. Казалось бы, какое отношение эта проблема может иметь к владельцу сайта? Оказывается, не просто имеет отношение, но и может стать причиной больших проблем.
Например, время генерации страницы может составлять 0.01 секунды, а время передачи страницы клиенту даже с компрессией может занимать от 5 до 50 секунд и более.
В течение всего времени передачи страницы клиенту веб-сервер будет держать в памяти практически бездействующий процесс Apache, который будет только дожидаться завершения передачи данных, но не сможет высвободить память и высвободиться сам, чтобы обработать другой запрос.
Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.
Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.
В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю.
Предположим, что на каждый сайт поступает по 100 запросов в секунду.
Система А: обработка 100 запросов в секунду потребует одновременной работы 100 самостоятельных процессов веб-сервера! "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы. Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 10Г оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц. Т.е. производительность системы А никак не связана с производительностью PHP и продукта.
Система Б: за первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час. Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 200М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду. Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов.
Очень наглядный пример, который демонстрирует, насколько велико влияние медленных каналов пользователей на общую производительность веб-системы. Веб-сервер очень неэффективно расходует оперативную память на медленных каналах.
Здравсвуйте, если кто-нибудь знает, подскажите пожалуйста:
При попытке обновления на работающем сайте PHP c 4-й до 5-й версии пропадает возможность логинится пользователям. Все страницы для неавторизованных отображаются нормально, но при любой попытке входа(в том числе и для админа) переадресует на пустую страницу.
FastCGI не дает прироста производительности на Друпал. Даже наоборот, об этом свидетельствует статья очень уважаемого человека - Дриса Байтаерта. FastCGI дает увеличение безопасности сервера.
Комментарии
eAccelerator или APC
А ещё не использовать PHP в блоках и страницах.
И как финальная стадия, перейти на FastCGI
Объясните пожалуйста: в чем преимущества FastCGI?
И как его использовать?
использование рнр в блоках замедляет работу сайта? Просто у меня на главной странице - 4 блока построеных на рнр (сниппеты). Я использую их для выдачи различных типов последних материалов.
Но я считал, что таким образом нагрузка на сервер будет меньше, чем при использовании views....
Поставь block chache на эти блоки, в настройках укажи зависят они от страницы или от пользователей - будет быстрее.
Я почти все блоки закэшировал.
«Wizard85
А ещё не использовать PHP в блоках и страницах.
И как финальная стадия, перейти на FastCGI»
FastCGI для Php не дает прироста. Об этом свидетельствует статья оч. уважаемого человека Дмитрия Котерова. http://dklab.ru/chicken/nablas/49.html ... Хотя об этом выше написали уже)
А еще способы есть?
У меня сайт на ник.ру - не знаю: поставят туда акселераторы или нет.
Нашел инструкцию по установке APC на хостинге nic.ru, поставил, время выполнения php сократилось в 3-4 раза.
Не знал что время Page execution time was 3512.58 ms. которое показывает Devel зависит от скорости канала.
На 128kB/s - Page execution time was 2025.61 ms.
На 512kB/s - Page execution time was 597.35 ms.
http://forum.typo3.biz/showthread.php?t=5808
Инструкция: установка php акселератора APC на хостинге nic.ru
(тарифный план 301)
выбираем PHP 5.2.2
ставим модули: curl gd iconv mbstring mysql xml zip gzip
(хотя их можно потому самим включить в php.ini)
включаем .htaccess для сайта ( На главную > Веб-сервер > Сайты > ваш-сайт.ru )
создаем юзеров
база: ставим utf8_general_ci в phpMyAdmin
SSH - инструкция здесь:
http://hosting.nic.ru/support/ssh/index.shtml
полезные вещи типа mc естетсвенно работают
http://pecl.php.net/package/APC
wget http://pecl.php.net/get/APC-3.0.16.tgz
Смотрим на инструкцию по установке:
$ gunzip -c apc_x.y.tar.gz | tar xf -
$ cd apc_x.y
$ /usr/local/php/bin/phpize
$ ./configure --enable-apc --enable-apc-mmap --with-apxs --with-php-config=/usr/local/php/bin/php-config
$ make
$ make install
И делаем почти тоже самое:
/usr/opt/php5/bin/phpize
./configure --enable-apc --enable-apc-mmap --with-php-config=/usr/opt/php5/bin/php-config
make
make test
далее в папке modules имеем файл apc.so
создаем папку php_extensions и копируем туда apc.so и все php extensions из /.ro/usr/opt/php5/lib/php/extensions
копируем php5.ini в свой каталог (там уже лежит файл .my.cnf)
переименовываем его в php.ini
и редактируем
Код:
<?php
register_globals=0
allow_url_fopen=1
max_input_time=60
max_execution_time=30
safe_mode=0
error_reporting=2039
session.save_path=/tmp
allow_url_include=0
file_uploads=1
magic_quotes_gpc=1
default_charset=
default_socket_timeout=120
memory_limit=48M
post_max_size=10M
upload_max_filesize=10M
#extension_dir="/opt/php/lib/php/extensions/"
extension_dir="/home/ИМЯ_ЮЗЕРА/php_extensions/" extension=zlib.so
extension=xml.so
extension=iconv.so
extension=curl.so
extension=gd.so
extension=zip.so
extension=mbstring.so
extension=mysql.so
extension=apc.so
.my.cnf
Код:
mysql.default_host=ИМЯ_ЮЗЕРА.mysql
mysql.default_port=3306
default_character_set = utf8
перезапускаем апач (для этого есть синяя иконка в админ панели хостинга, но помоему можно и в SSH перезапустить) создаем файл с <?phpinfo();?>
и проверяем что нам показывает - там будет секция с apc
как посмотреть расход памяти:
копируем файл apc.php из дистрибува, переименовываем его, вбиваем в нем логин\пароль
Если кто желает спонсировать развитие этого мануала, то вот партнерская ссылка (nic.ru платит партнерам процент от платежей приведенных ими клиентов). Замечу, что о nic.ru только у меня сложилось хорошее впечатление. Ставлю туда уже 3-его клиента.?>
интересно! А теперь сравните с eAcceleratorом
Пока некогда, нету способа точного тестирования, да и APС пока устраивает.
надо бы попробовать! у меня там тоже сайт. хостинг устраивает по всем техническим параметрам (скорость, память и т.д.), но вот техподдержка - мягко говоря, оставляет желать лучшего. на некоторые мои вопросы ответа так и не получил, сам разбирался.
Наше тестирование показывает, что PHP-акселераторы отличаются друг от друга по производительности в среднем на +-5%.
Так что имеет смысл поставить любой, по вкусу, лишь бы с ним ваш сайт работал.
P.S.: есть некоторое отличие по объёму потребляемой памяти, но документы далеко.
навскидку выгоднее по набору характеристик оказался eAccelerator.
Ещё надо думать о APC, ибо он со временем должен войти в поставку PHP 6.
block chache ставил. В настройках модуля поставил enable.
Но почему то не все блоки можно кешировать... и те которые нужно не кешеруются. заходишь в настройки блока, а там о block chache ни слова. А те которые не нужно кешируются и в найстроках блока можно выбирать...
Почему так?
block chache создает копии существующих блоков - кэшируемые блоки - ими нужно заменить те блоки, которые хочешь закэшировать.
по моему, узкое место в Друпале - это база, а уж никак не PHP
Dimm, а понял!
спасибо!
и там можно настроить, что когда инфа обновилась и кеш обновляется?
да
Кэш обновляется весь?
не весь а блоккэша
После установки APC в 2 раза уменьшился потребляемый объем памяти.
Загрузка процессора осталась той же
Объясни мне пожалуйста, что этот FastCGI дает?
То есть за счет чего идет ускорение?
скрипты передаются средствами Apache mod_fastcgi на вход интерпретатора PHP.
Производительность достигается за счет кэширования некоторых промежуточных данных.
Т.е. скрипт не интерпретируется каждый раз при выполнении.
у меня на хостинге в настройках сервера есть этот FastCGI
можно галочку поставить - чтобы включить
Вопрос - это то или нет, в смысле будет у меня ускорение или нет?
а что за хостинг? у меня тоже можно включить, тока он фиг заработает. надо патч ставить.
Хостинг Русоникс
тогда не знаю
Ну спрошу у хостера
а при включении PHP как FastCGI
нет каких либо подводных камней?
Хотя, как я слышал, на бесплатных FastCGI только и работает.
У меня есть иногда какие-то внутренние ошибки, но к сожалению времени разобратся нет пока. Но то что он быстрее это 100%.
Нашел объяснение ускорению работы сайта и уменьшение потребляемой памяти при включении сжатия страниц gzip.
Как ни странно нашел это в тестовой установке битрикса
Почему умирают сайты?
Оперативная память: медленные каналы
Еще один аспект проблемы – это медленные каналы пользователей вашего сайта по меркам веб-сервера. Казалось бы, какое отношение эта проблема может иметь к владельцу сайта? Оказывается, не просто имеет отношение, но и может стать причиной больших проблем.
Например, время генерации страницы может составлять 0.01 секунды, а время передачи страницы клиенту даже с компрессией может занимать от 5 до 50 секунд и более.
В течение всего времени передачи страницы клиенту веб-сервер будет держать в памяти практически бездействующий процесс Apache, который будет только дожидаться завершения передачи данных, но не сможет высвободить память и высвободиться сам, чтобы обработать другой запрос.
Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.
Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.
В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю.
Предположим, что на каждый сайт поступает по 100 запросов в секунду.
Система А: обработка 100 запросов в секунду потребует одновременной работы 100 самостоятельных процессов веб-сервера! "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы. Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 10Г оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц. Т.е. производительность системы А никак не связана с производительностью PHP и продукта.
Система Б: за первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час. Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 200М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду. Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов.
Очень наглядный пример, который демонстрирует, насколько велико влияние медленных каналов пользователей на общую производительность веб-системы. Веб-сервер очень неэффективно расходует оперативную память на медленных каналах.
К сожалению, пользователя с медленным каналом (а в России по большей части интернет медленный) это не волнует.
Оптимизируем загрузку PHP-кода в 22 раза, или почему FastCGI не ускоряет PHP
http://dklab.ru/chicken/nablas/49.html
полезно. кратко пробежался. будет время обязательно изучу. спасибо за ссылку.
Здравсвуйте, если кто-нибудь знает, подскажите пожалуйста:
При попытке обновления на работающем сайте PHP c 4-й до 5-й версии пропадает возможность логинится пользователям. Все страницы для неавторизованных отображаются нормально, но при любой попытке входа(в том числе и для админа) переадресует на пустую страницу.
Может у php5 настройки другие, памяти не хватает.
FastCGI не дает прироста производительности на Друпал. Даже наоборот, об этом свидетельствует статья очень уважаемого человека - Дриса Байтаерта. FastCGI дает увеличение безопасности сервера.