LINUX.ORG.RU

Зачем собирать файлы web-приложения в один?

 ,


0

1

Начитался тут о повышении производительности Zend Framework, и в частности о сборке самой библиотеки в один бооольшой файл. В ней и правда очень много файликов-классов (и пр.).

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

Теперь призадумался... Если речь идет о «высоконагруженном» проекте, который требует оптимизаций, то конечно мысли о говнохостингах сразу отпадают. Все будет работать на выделенном сервере под управлением Его Величества Linux (Ubuntu тоже вроде королевских кровей :)

Но, если Apache постоянно дергает с диска кучку файликов, то не вынуждена ли будет ОС держать их в файловом кэше (оперативочке)? Может я конечно неправильно понимаю назначение этого файлового кэша, который бесстыдно пожирает мою оперативку на домашнем компике... Разве тем самым дисковое IO не исчезнет волшебным образом?

Впрочем, если уж руки чешутся оптимизировать библиотеку, а не свой кастомный проектик, может было бы удобнее (и практичнее) поместить файлы библиотеки на ramdisk?

Мне кажется, что решение о слиянии файликов рождается в головах программистов. Но проблемы решаются не только ими, есть еще и администраторы :)

А что думаете вы, уважаемые собратья аналитики?

★★★

на подобный вопрос, нормально ответит только bechmark на:

минимальной нагрузке

стресс тесте

ситуации приближенной к реальной.

qnikst ★★★★★
()

Если речь идет о «высоконагруженном» проекте, который требует оптимизаций

то явно фреймворками и прочей тяжелятиной никто пользоваться не будет.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

то явно фреймворками и прочей тяжелятиной никто пользоваться не будет.

А если это был стартапчик? Который надо было слепить побыстрее и попробовать на рынке. И получилось как всегда :)

valich ★★★
() автор топика
Ответ на: комментарий от valich

А если это был стартапчик? Который надо было слепить побыстрее и попробовать на рынке.

Ну так надо же выбирать: либо быстро и «на отцепись», либо медленно и надежно.

Eddy_Em ☆☆☆☆☆
()

По поводу файлового кэша - ОС будет его создавать, если только для него есть избыток места. Это на самом деле очень ускорит доступ, но только до тех пор, пока процессы/нити Apache и прочих пожирателей памяти не заставят это место освободить, так что потом - лезь по-новой на диск. Видимо, на ramdisk лучше, тем более что они окажутся там еще до первого обращения.

ABW ★★★★★
()
Ответ на: комментарий от ABW

ABW

По поводу файлового кэша - ОС будет его создавать, если только для него есть избыток места.

ну а если места нет, то придётся этот громадный php-файл каждый раз грузить по новой. ИЧСХ, наверняка половина из него (если не больше) не нужна. К примеру, если это форум, то файлы админки нужны только кода админ заходит, какой смысл грузить их в память на каждом обращении любого юзера? Ну и т.д. и т.п.

ИМХО в большинстве случаев громадный файл не нужен. Хотя конечно в каком-то конкретном случае это возможно и не так.

drBatty ★★
()
Ответ на: комментарий от Eddy_Em

Ну и ССЗБ.

Отчего же? Большинство не сможет написать свой лисяпед под тяжеловесный проект, который будет работать быстрее, чем какой-нибудь фрейсворк написанный знающими людьми (не забывать про кеширование, apc и т.п.)

VirRaa ★★★
()
Ответ на: комментарий от Eddy_Em

Если речь идет о «высоконагруженном» проекте

то явно фреймворками и прочей тяжелятиной никто пользоваться не будет.

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

Wizard_ ★★★★★
()
Ответ на: комментарий от Eddy_Em

Фреймворк — это не «чужой проект», это набор типичной логики веб-приложения и основа для наращивания своего приложения. И производительность тут никаким боком, я бы вообще поспорил, что ваш собственный велосипед будет быстрее даже той же симфони2.

Wizard_ ★★★★★
()

Насколько я понимаю, этот «способ» призван обойти множественные операции чтения с диска.

После первого чтения все надежно оседает в page cache и всяческий смысл подобных «оптимизаций» начисто теряется. Даже напротив, ты сильно проиграешь в скорости из-за того, что ненаглядный похапе будет каждый раз парсить огромный файл, даже если нужны будут полторы миниатюрных функции.

А что думаете вы, уважаемые собратья аналитики?

Я думаю, что ты к разработке не имеешь никакого отношения и крайне некомпетентен в этом вопросе.

red_eyed_peguin
()

в частности о сборке самой библиотеки в один бооольшой файл

Мусор тоже собирают в один большой мешок. Чтобы выкинуть. Где-то также стоит поступить и с PHP ибо сложно придумать что-то глупее, чем при каждом запросе пользователя парсить одни и те же скрипты.

d9d9 ★★★★
()

производительности Zend Framework

Если речь идет о «высоконагруженном» проекте

ну ты понял :)

xpahos ★★★★★
()
Ответ на: комментарий от Eddy_Em

то явно фреймворками и прочей тяжелятиной никто пользоваться не будет.

почему это? Или вы думаете что команда студентов(как часто это бывает) напишет лучше?

ggrn ★★★★★
()

Не читайте больше блогов «программистов» осиливших труды типа PHP для Чайников за 2 часа и решивших занятся оптимизацией.

Есть APC (и не только, много всяких), который с выключеным stat (http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat) вообще никогда не будет обращаться к диску. Если хостинг не умеет APC, лишний раз стоит задуматься нужен ли этот хостер вообще - VPS за 5$ навалом.

BobiKK
()

valich

в частности о сборке самой библиотеки в один бооольшой файл.

А в общем там наверно говорилось о статике? Скрипты, цсс, спрайты, и т.д. ...

Объединять код по-моему жуткая тупость, читать и редактировать его потом как? Или городить костыль который для продакшна будет всё склеивать?

Kalashnikov ★★★
()
Ответ на: комментарий от red_eyed_peguin

Даже напротив, ты сильно проиграешь в скорости из-за того, что ненаглядный похапе будет каждый раз парсить огромный файл, даже если нужны будут полторы миниатюрных функции

Ну вот поэтому люди и используют акселераторы :-) В этом случае в памяти будет храниться уже представление данных, используемое интерпретатором.

sjinks ★★★
()
Ответ на: комментарий от Eddy_Em

диванные кукаретики не могут ошибаться. Окей завтра отказываемся всей командой от фреймворка пишем свой.

ggrn ★★★★★
()
Ответ на: комментарий от Eddy_Em

Kohana, например. Фреймворк — не готовый движок.

Или штуки типа Thrift — зачем писать с нуля, когда есть хорошее готовое решение? FourSquare вообще на LiftWeb работает.

note173 ★★★★★
()
Ответ на: комментарий от resurtm

Существует ряд инструментов, кэширующих в разделяемой оперативной памяти (shared memory) оттранслированное (скомпилированное - прим. ТС) внутреннее представление PHP-кода. Таким образом, при повторном включении PHP-файла он уже не транслируется, а байт-код берется из кэша в памяти. Естественно, это значительно ускоряет работу. Одним из таких инструментов является eAccelerator.

Ответ где-то здесь водимо. Я обратил внимание на туманное упоминание автора о том, что eAccelerator «не любит» много мелких файлов. Что странно для настроек указанных в статье, где ему (eAccelerator`у) указали «не смотреть» на дисковые файлы. Не проверять их возможные изменения и не синхронизировать изменения в кэш.

Было бы очень неплохо разобраться с этим моментом. Если заставить eAccelerator «полюбить» множество мелких файлов кода для кэширования, то не пришлось бы городить объединения и адаптировать свое приложение под новый механизм autoload.

valich ★★★
() автор топика

«высоконагруженном» проекте

php

/0

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.