Всем привет. Столкнулся с неприятными фактами- программа работает медленно. Испытываю на 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 ядерный проц от интела.. скоро обещали =)

  


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