Скорость работы программной начинки сайта

А почему именно с помощью внешних средств? Результат будет менее точным, т.к. будут влиять многие лишние факторы. Мне кажется, лучше средствами языка выводить время генерации страницы.

Не знаю, поможет ли это, я в этой штуке не спец, но на всякий случай -

вот ссылки:

http://perl.apache.org/docs/1.0/guide/performance.html#ApacheBench

http://en.wikipedia.org/wiki/ApacheBench

Mmonger, да дело в том что с разработчиками не особо хочется связываться... Просто взять и самим проверить.

Jackyk, спасибо, я на Вас даже больше не сержусь :)

Ну если нужно точно... Там буквально несколько строк кода ;)

😕 😕 😕

Это очень приятная новость, конечно, но отчего Вы на меня сердились раньше??? Минусов я вроде Вам не ставил, разногласий особых не помню... Что мы не поделили, о чем дискутировали, напомните, пожалуйста. Прошу прощения за оффтоп.

Скорее всего чистое время генерации страницы Вам не нужно (посчитать его можно именно расставив по коду операторы вывода куда-нибудь текущего времени с высокой точностью). Скорее всего Вам нужно понять насколько быстро в целом сайт будет любые страницы (или определенную страницу) отдавать наружу. Проверка эта в общем случае называется "нагрузочное тестирование". В простейшем случае сводится к запуску нескольких клиентов для обращений к странице в цикле и логировании результатов. Можно написать простой скрипт, эмулирующий работу одного пользователя, самому (например сделать bat файл для запуска утилиты wget в цикле), или воспользоваться, бесплатными (или платными) промышленными средствами. Например, можно взять Microsoft Web Application Stress Tool. Простая в обращении программа, хелп правда нужно читать обязательно чтобы понять теорию тестирования (3 абзаца).

Это если в лоб. Если знать архитектуру системы, то наверняка сравнение можно провести и более качественно, зная узкие места. Из общих соображений мне кажется что PHP или Ruby будет совершенно все равно, т.к. оба языка скриптовые. То есть интерпретатору нужно время на открытие файла с кодом, парсинг его и интерпретацию всех инструкций при каждом запросе к скрипту. А это примерно одинаковое время для Perl, PHP, Ruby, ASP и пр. Для компилируемых языков (ява, технологии дотнет и пр.) естественно время работы каждого скрипта значительно меньше.

Если у веб-сервера есть средства для кэширования приложений (все что mod_... для Апача или др.) то приложение в целом будет работать быстрее (не нужно тратить время на загрузку файла в память и некоторые другие частые операции), но от самого языка - практически никак не зависит. Файловые операции и проч. стрингоориентированная ботва во всех языках по скорости примерно одинакова, если глубоко в регулярные выражения не лезть.

Также из общих изображений - для веб-приложений с приличного объема базой данных язык также не будет играть решающего значения, поскольку все время будет отъедаться на всякие select-update на уровне СУБД.

stealthy, спасибо огромное!

Тут выяснил, что особенность системы администрирования такова - все картинки и даже doc храняться в БД (Postgre). Из-за этого размер ее раздут аж до 1Гб! :(

Не это ли имеет решающее значение?

На сколько можно оптимизировать (или наоборот...) скорость работы, если в базе хранить только ссылки на документы и картинки?

Да не за что :).

Чтобы точно ответить - нужно понимать внутреннее устройство Postgres (или правильно Postgre?). Мне кажется, что объем базы на скорость выборки из нее влиять не должен, т.к. доступ к файлам с данными производится в произвольном режиме, по индексам (если они есть - проверьте!). То есть если нужна запись в середине одногигового файла - она возьмется с той же скоростью что и из 10 килобайтного. Другое дело, что обслуживать такую БД сложнее, при записи в нее могут быть тормоза (если применен какой-нибудь кластерный индекс или еще что-то подобное) и с архитектурной точки зрения совершенно неверно.

Плохо то, что картинка каждый раз будет выдираться из БД в память и оттуда сливаться навстречу радостным пользователям. Это большой расход памяти, приличное время выдирания картинки из blob, неизвестная эффективность при одновременном запросе одной картинки 100 пользователями, лишняя процессорная загрузка для вывода бинарных данных наружу и так далее. Поэтому конечно в любом случае картинки нужно выносить на уровень файловой системы, а в базе хранить только ссылки на них. Опять же при такой схеме за выдачу картинок наружу будет отвечать уже сам Апач (на форуме где-то читал что на очень нагруженных проектах под выдачу картинок вообще отдельный веб-сервер ставят, типа Nginx, кажется).

Можно 100% гарантировать что скорость работы увеличится, но насколько - зависит от остальной мишуры и особенностей устройства и настройки СУБД. Может выигрыш будет всего 3-5% (по скорости), а может в разы. Но учитывая, что не скоростью единой - нужно все ресурсы считать до кучи - то я бы обязательно рекомендовал от такой схемы уйти.

На Ruby on Rails? Система сама по себе не быстрая, но плюсы это скорость разработки и кеширование самим движком. Интересно чем обусловлено хранение изображений в бд не понятно и использования postgre. Postgrе сама база не из быстрых нацеленная больше на безопасность и сохранность данных а не на скорость.

sun, плюс еще есть один - привязка фирмы владельца сайта к разработчику ;) Лично я не знаю больше никого, кто бы с Руби работал...

Значит кеширование все же есть... это хорошо. Но сам mod_ruby по заявлению сисалмина очень криво встал на Апач...