Форум dkLab и Denwer

[anonymous_incognito]

Vitaly Puzrin wrote:

Дело было давно, форум IPB на 2000 уников в сутки, сервер (только не смейтесь) на целерон 2000 и 2 гига памяти.

будете смеяться, но я всё-таки прокомментирую. Если бы поменяли проц на p4, то ваши скрипты ускорились бы на 30%. А на корку с 6-8мб кеша - в 10-20 раз (полагаю с коре2 с 6MB кешем, пхпешка стала умещаться там, за счет чего и такой скачок). Без акселераторов. Без мемкэша. Без памяти. Без нгинкса и 500-го бэд-гейтвея :)
На последних корках (семёрки) правда выигрыш меньший (по сравнению с корками), но система в целом (апаче, мускул, шедулеры) отзывчивее. Довольно толсто.

К чему это? К тому, что отладить или использовать в общем случае тот же самый апач удобнее, чем велосипедить и иметь кучу геморроя с уже написанным софтом, который не всегда без вышеупомянутой болячки, запустится на лисипеде. А количество производимых мега-проектов каждым конкретным индивидуумом не на столько большое, чтобы говорить, что ентот самый индивидуум генерит "высонагруженные" проекты ежедневно :) Мораль всё-таки в том, что для каждого лисипеда высокой нагрузочной способности требуется свой пилот, который и будет крутить педали под конкретный девайс :)

[Guest]

Дмитрий Котеров wrote:

_а-я_ wrote: До этого я хотел чтоб nginx сразу отдавал PHP- fcgi через php-fpm/ Но прочитав тут все, понял что этого не стоит делать. Это так? Неправильно говорить "не стоит". Лучше говорить - "по скорости разница будет совсем незначительной, и fastcgi тут не является панацеей". Ну а память при fastcgi выиграете, да, но тоже не чтобы уж очень значительно тоже (при правильных настройках апача). _а-я_ wrote: Прочитав все, я понял, что лучше не использовать инклуды. А «забихать» все в один большой php-файл по возможности. Главное, чтобы это не ухудшало читабельность программы и не усложняло ее разработку. Все-таки человеческое время дороже машинного. Плюс - эффект начинает проявляться, только если исходников очень много (1М и больше). Если у Вас кода всего-то на 100КБ, то смысла заморачиваться вообще нет. _а-я_ wrote: если PHP транслирует байт-код, а eAccelerator – кэширует, почему нельзя на сервере хранить именно в этом «байт-коде» Zend Encoder это как раз и пытается делать, только смысла нет совсем: достаточно в shared memory хранить оттранслированную версию. Кроме того, у eAccelerator есть режим сохранения байт-кода во временные файлы тоже. В любом случае, когда байт-код на лету генерится, это гораздо удобнее, чем хранить его в виде файлов (потому что исчезает фаза компиляции при разработке).

Спасибо. =)
Вроде справился.
Избавился от инклудов. Использовал следующую структуру.
base.php <- chat.php(140.kb)
base.php <- forum.php(50kb)
..
и т.д.
для каждого действия использовал отдельную пользовательскую функцию,
чтоб дело происходило как бы в chroot’e

скорость генерации страниц увеличился в разы. И eAccelerator'ом "добил" уже! =)
итого, скорость генерации упала с 0,05 до 0,008сек
даже сам как-то не поверил.

Дело происходит на слабом VDS(300Мгц, ОЗУ: 64МБ)
Так же полностью перешел на свзяку
Nginx + php-fpm + php-Fastcgi
Итого еще от 20 до 35Mб оперативки свободно)

Кроме этих процессов, еще запущен MySQl, почта и по мелочи)

Хотя я в это новичок) может что-то не так понял, но мне кажется эт большой результат.)

[eXed_]

ради эксперимента провел тесты на денвере (разумеется под виндой)

Code (php):

скопировать код в буфер обмена

//index.php(88),1,"9.244 ms","9.244 ms","9.244 ms","9.244 ms","100.00% / 100.00%" require_once('../class/db_mysql.php'); //index.php(91),1,"9.095 ms","9.095 ms","9.095 ms","9.095 ms","100.00% / 100.00%" require_once('Z:\home\test\www\class\db_mysql.php'); //index.php(94),1,"10.21 ms","10.21 ms","10.21 ms","10.21 ms","100.00% / 100.00%" require_once('Z:/home/test/www/class/db_mysql.php'); //index.php(98),1,"12.45 ms","12.45 ms","12.45 ms","12.45 ms","100.00% / 100.00%" ini_set (www.php.net/ini_set)('include_path', ini_get (www.php.net/ini_get)('include_path') . PATH_SEPARATOR . 'Z:\home\test\www\class'); require_once('db_mysql.php'); //index.php(100),1,"12.90 ms","12.90 ms","12.90 ms","12.90 ms","100.00% / 100.00%" ini_set (www.php.net/ini_set)('include_path', ini_get (www.php.net/ini_get)('include_path') . PATH_SEPARATOR . 'Z:/home/test/www/class'); require_once('db_mysql.php');

Относительный путь можно использовать, ожидал худшего.
Неправильный DIRECTORY_SEPARATOR тормозит.
include_path - фаворит по торможению инклудов.

Объединение в один файл, без вариантов.

[Гость ЛГА]

Народ а можно описать процедуру объединения библиотек PHP в один файл? У меня стоит сейчас NGNIX как форвард и Apache как бэквард плюс eAccelerator на PHP. Но как то притормаживает отправка сообщений на форум хочу вот сделать как написано в статье но незнаю как это сотворить :)

[Maus]

Гость ЛГА
Вы уверены, что дело в библиотеках? Сделайте сначала профилирование

[Гость ЛГА]

А чего это? Я просто далек от этого и если можно то поподробнее или где почить можно. За ранее спасибо. Но всё равно хотелось бы сделать как написано в статье.

[Гость ЛГА]

Статьи по профилированию PHP я нашел, попробую сделать. Но попрошу описать процесс объединения библиотек в один файл :)

[Maus]

Гость ЛГА
м, попробуйте поискать - может, для этого есть какие-то специальные техники. Мне в голову приходит только чтение файлов с диска, поиск в файле require/require_once и include/include_once, найденное ставится в очередь файлов, а сами строки вырезаются. Очищенный остаток льётся в один большой файл.
Но как-то это грубо, мне кажется. Зато огромное поле для развлечений. Автолоадинг ещё.

[patt]

Из личного: опыта заменив не проекте Apache на lighttpd проект перешел из состояния "после рестарта грузит страницу по минуте, и через 30мин отваливается" в состояние "работает нормально особо не нагружая процессор"

[alpaca]

Прошло уже много времени с момента обсуждения. Вышли новые версии и всё такое. Какие мнения на сегодняшний день?

[Дмитрий Котеров]

patt
Ну тут как бы как в анекдоте: "блоха без ног оглохла".
О том и статья вся...

[lurkerr]

Дмитрий, я, следуя вашей статье, тоже у себя сделал merge всех классов фреймворка (Kohana) и был доволен как слон.
Но тут на днях нашел другой бенчмарк, у товарища немного другой результат получился: phpixie.com/blog/benchmarking-autoloading-vs-combining-classes-into-a-single-file/
Т.е. слитый файл проиграл вчистую автозагрузчику. Это из-за огромного classmap такое получилось? Или времена изменились, и автозагрузка нынче рулит?

[Vernon]

П№ool! Thanks fОїr this articlпЅ…! Feel free to visС–t my web blog :: в…®пЅ…menti ЖЉemiЙ—ov (demidov83.jimdofree.com/)