Всем привет. Столкнулся с неприятными фактами- программа работает медленно. Испытываю на ASUS Lamborghini, для справки- 2Gb RAM, 2.16 Intel Core 2 Duo

Пишу веб скрипт. Который по идее разрабатывается как высоконагруженый....

Генерация страницы занимает порой несколько секунд. Даже на тех страницах, где нет запросов к БД.

Объем кода сравнительно небольшой. Суммарй объем всех файлов cgi и  pm составляет 180кб


Особенность системы в том, что она поделена на модули. Каждый модуль выполняет свои функции- фотогалерея, форум, блоги и т.д. Каждый модуль выполнен в виде модуля Perl - pm файл.

Обращение к модулям системы происходит посредствам URL 

site.ru/gallery/view/23
site.ru/blogs
site.ru/forums/show/12
и т.д.

В главном файле, который и запускается, стоит swith примерно такой конструкции




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

Еще я использую модуль Switch в главной сайте программы и в каждом модуле он тоже подключается, т.к. там он тоже используется. На сколько это плохо? Подключается ли он каждый раз заново или Perl умеет не загружать дважды одно и то же?

Какие вообще посоветуете провести работы для ускорения работы программы? Если в браузере нажать раз 20 подряд F5 - в памяти появляется все 20 процессов Perl и пока все отработают проходит несколько минут...


Это сообщение отредактировал(а) rcdimon - 27.9.2008, 18:14

use подключает модули еще на стадии компиляции. Если вы хотите делать это в рантайме, то используйте require.

Дважды в одном процессе модуль не загрузится.

Ну для начала, имхо, попробуйте пересмотреть свой код. Скорее всего проблема в нем, а не в том, что лишние модули подргужаются.
Потом почитайте про mod_perl.

Дело в том, что это моя далеко не первая программа на перл. Были и на много большие. Писал я в том же стиле, точно так же.. В других программах подобного не наблюдалось

Да вопрос оптимизации очень остро стоит есть куча объектно ориентированных модулей, которые подключаются... задержка около 1-2 сек... Собираемся решить перейдя на mod_perl, но мне кажется что это не сильно поможет. В следствии чего возникает вопрос: можно ли откомпилировать статические модули (например ядро системы) - в тип dll (к примеру), которые можно будет подрубить потом и которые будут работать быстро(так как они откомпилины)... или это из области фантастики? 

Это сообщение отредактировал(а) DaemonSuw - 27.9.2008, 20:19

rcdimon, а вам правильно сказали - use подключает на этапе компиляции.. т.е. ему пофигу на всякие if - then.

Если нужна производительность - fastcgi или mod_perl.

А вообще - попробуйте профайлер подключить - увидите куда время уходит. А то делать заявления, что тормозит из-за того то ... как то необоснованно.

А как его подключить?   

rcdimon, c бубном и только с бубном..
у вас я так понял CGI ? - эт просто скрипт - поэтому проблем быть не должно

Сначала прочитать доку:
http://search.cpan.org/~ilyaz/DProf-19990108/DProf.pm

По идее достаточно написать в начале CGI скрипта


после запуска скрипта найти логи профайлера и посмотреть их с помощью dprofpp

Спасибо, попробую.

Посоветуйте еще, пожалуйста, где найти документацию о том, как перейти с cgi на mod_perl

rcdimon, 
тут: http://perl.apache.org/docs/index.html
и тут: http://perl.apache.org/docs/1.0/guide/porting.html

вообще говоря, есть режим совместимости, когда вы  не хотите менять сами скрипты..  они просто работают быстрее - уличная магия =)
а есть mod_perl API - это когда вы программируете под apache - я использовал именно такое.

А еще - если только начали - по пробуйте Catalyst.. я сам только сегодня начал с ним знакомится - но он мне уже нравится! с ним можно ваши программы запускать как FCGI, CGI, mod_perl, под собственным сервером, не меняя модули!

Буквально в соседнем топике человек просил ссылки на документацию.

ЗЫ: помнится на http://perl.apache.org/ видел статью типа "Migrating from CGI to mod_perl"

Добавлено через 53 секунды
Опередили)

Мне в принципе разнообразие не нужно. У меня есть довольно серьезный проект, который мне необходимо сначала разработать локально, а работать он будет на выделенном сервере под *nix с апачем конечно. Планируется большое число пользователей онлайн- поэтому хотелось бы выбрать наиболее быстрый вариант. 

Так же не помешают статьи об оптимизации самого кода.

Что касается исправления скриптов под mod_perl- то это не проблема. Если будет надо- исправим легко

Уважаемый rcdimon, прежде всего, фраза



для людей, не первый год разрабатывающих ПО под mod_perl звучит по-детски наивно  (и это не "понты", а суровая правда жизни).



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

По поводу оптимизации программы присоединяюсь к совету sir_nuf_nuf по поводу DProf - этот модуль поможет найти методы и функции, которые  отрабатывают дольше всего. Но это не универсальный модуль, он помогает найти узкое место только в части случаев, кроме того, повышением производительности медленного фрагмента Вам придется заниматься самостоятельно - для этого автоматизированных модулей нет. Не имея опыта это сделать крайне сложно.
В своей практике для определения узких, с точки зрения быстродействия, мест я использую модуль Test::Timestamp, только все чаще становится проблемой, ограничение в 6 разрядов после запятой во временных отсчетах.

Серьезный web-проект обычно включает:

1. Сервер распределения нагрузки (frontend)
2. Один или несколько кэширующих серверов для статики (назовем их frontend cache)
3. Один или несколько серверов, на которых выполняются скрипты (backend)
4. Один или несколько (обычно с использованием репликации) серверов БД (database)
5. Один или несколько кэширующих серверов для скриптов (назовем их backend cache)

Как это все будет работать на "выделенном сервере под *nix с апачем конечно"?   

главное отжать у руководства 70 ядерный проц от интела.. скоро обещали =)

  


Вот бы и нам такой, а то столько сил уходит на оптимизацию, кластеризацию и кэширование   

   gallery2 на php очень медленно работает, много памяти ест, и все равно в каком режиме php или fastcgi или mod_php

ЗЫ mod_perl на много быстрее заработает?

Это сообщение отредактировал(а) gcc - 28.9.2008, 10:47

В десятки, а местами может и сотни раз быстрее

Это сообщение отредактировал(а) KSURi - 28.9.2008, 11:28

а mod_perl и mod_php разные чтоли совсем?  



Это сообщение отредактировал(а) gcc - 28.9.2008, 11:35

Я сталкивался с этим, я думаю, что Gallery2 просто написана не достаточно оптимально. Использует Smarty, который сам по себе довольно тяжелый и т.д. Основной выигрыш использования mod_perl по скорости перед обычным cgi в том, что Perl находится уже в памяти и ему не надо тратить время на загрузку перед выполнением сценария. Если сам сценарий тяжелый- то, конечно, летать не начнет.



 Я где-то слышал, что php быстрее начинает исполнять сценарий- поэтому на небольших и несложных программках php выгоднее чем perl cgi. Но после загрузки в память интерпретатора Perl- он работает все-таки быстрее, чем php. Используя mod_perl можно освободиться от накладных расходов на загрузку интерпретатора в память.





Я не разрабатывал никогда до сих пор По под mod_perl- иначе не создавал бы эту тему   





Согласен на все 100%. Поэтому решил осваивать )




Очень интересно, всегда было интересно как это устроено ) Таких вещей я пока не делал, конечно. Где можно подробнее ознакомиться с технологиями высоконагруженых систем? Ну кроме репликации баз данных- этого вроде во всех книгах про БД полно... Хотя и не помешает еще раз   


Могу дать погонять свой 71.5   

Это сообщение отредактировал(а) rcdimon - 28.9.2008, 16:15

Пропустил программу через профайлер, а потом его отчет через программу dprofpp

Получились следующие результаты




Т.е. как я понял что-то под именем Text::Balanced::_match_codeblock жрет половину времени выполнения программы, вызываясь 23 тысячи раз... Хотелось бы еще узнать что это такое и как с ним бороться   

rcdimon, если это результат одного запуска скрипта, то надо срочно делать предварительный заказ на всю партию компьютеров с новыми 70-и ядерными процессорами  


Интересный вопрос от разработчика  
Мои телепатические способности практически не развиты, возможно кто-то из коллег будет удачливее и напишет Вам какие нужно внести изменения в скрипт, чтобы все "залетало".

Ну да.. Одного )

Скажите хотя бы что такое 

Text::Balanced::_match_codeblock
Text::Balanced::_match_variable
Text::Balanced::_failmsg
Text::Balanced::_match_quotelike

Удалось снизить время выполения скрипта с 1.8 секунды до 0.2 просто заменив use на require (при подключении модулей) и отказавшись от использования Switch... В документации прочитал, что ему нужен для работы тот самый Text::Balanced.... 

Удалил Switch- исчезли все

Text::Balanced::_match_codeblock
Text::Balanced::_match_variable
Text::Balanced::_failmsg
Text::Balanced::_match_quotelike

Это сообщение отредактировал(а) rcdimon - 28.9.2008, 23:29

Имхо, такие вещи надо не "пальцем в небо" надо угадывать, а пошаговой отладкой.

Я не пальцем.. я документацию почитал   

Cpan.org

достаточно ли использовать для безопасности use strict и use vars (в котором $dbh и несколько хэшей ключи которого часто используются) может быть еще что-то надо или больше ничего не надо?

Это сообщение отредактировал(а) gcc - 30.9.2008, 02:53