Эта тема на forum.dklab.ru


Ярмантович В.: Производительность в очень крупном проекте
Ребята, работаю в крупной организации, требуется переписать большой и реально действующий проект с нуля.
Примерная нагрузка 250 млн. кликов в сутки.
Для разработки есть желание использовать Zend Framework, выкинув из него класс View и заменив его Smarty.
Кто знает, скажите, не загнется ли проект по производительности, если использовать такую основу?
Может есть вообще какие-нибудь советы по созданию крупных высокопроизводительных проектов?

// исправлено по желанию автора
Vitaminych:
Сам по себе ZF не самая быстрая система. Одна из самых распространенных проблем - большое количество подключаемых файлов, но она решается созданием одного большого файла, где есть всё, необходимое. Smarty тоже не очень шустрый, всё-таки дополнительный парсинг макросов и дополнительные функции, лучше в качестве шаблона использовать View всё-таки - чистый PHP.

Вы уверены в своей нагрузке? 250 млн. - это слишком круто. На столько круто, что яндексу не снилось (у яндекса ~75 млн хитов в сутки). Может быть 250 тысяч или 250 млн. хитов в месяц (8.3 млн. хитов в сутки)?
Ярмантович В.:
Да, извиняюсь. Где-то 250 тыс. уникальных посетителей (около 2,5 млн. хитов).
Но проблема еще в том, что траффик распределен не равномерно.
Наша статистика показывает, что 60% пользователей заходят на сайты крупной организации в обеденное время.

Может стоит использовать другой фреймворк? Я ознакомился с примерно пятью их представителями. Больше всего приглянулся CodeIgniter, который скорее набор полезных классов, чем сложная конструкция на подобие ZF. Однако в нем не работает поддержка Оракла (т.е она заявлена официально, но не работает. А следовательно придется придумывать что-то свое).
В общем, тяжело сделать выбор между медленным но качественным танком ZF, и лекгим но дырявым CodeIgniter`ом.
И с шаблонизатором, тоже большой вопрос. PHP сам по себе шаблонизатор, но шаблоны на нем не удобоваримы. С другой стороны Smarty - еще одна бронированная медленная машина, но за счет этого удобная и безопасная...

// исправлено по желанию автора
Vitaminych:
CodeIgniter мне тоже понравился, очень простой и удобный фреймворк. Реализация MVC, предлагаемая ZF, мне не очень нравится, предпочитаю более логичные URL, поэтому ZF использую также в качестве набора классов для облегчения жизни. В ZF для серьезных проектов есть хорошая реализация кэширования, в том числе с механизмом memcached.

Если среди фреймворков ничего не найдете, обратите свой взор в сторону коробочных CMS, например, 1С-Битрикс, он с Oracle дружит без костылей и нагрузку выдержит с большим запасом. Только камнями в меня не кидать за такое предложение ;) Кстати, в вашей "крупной организации", на сколько я знаю, есть своя CMS, чем не угодила? По-моему, лучше всего будет обратиться к коробочным CMS: готовая админка, поддержка разработчика, отлаженные механизмы на сотнях и тысячах других проектов. Стоимость не высокая, а времени сэкономить можно довольно много. В общем, плюсов хватает. Тем более, что проект у вас контентный, а не сервисный. "Доделать напильником" нормальную коробочную систему под многие проекты - задача вполне выполнимая. Да и многие "коробки" сами по себе являются фреймворками, просто не позиционируют себя в таком амплуа - боятся спугнуть обычных покупателей, кому слово "фреймворк" ни о чем не говорит. Явно позиционируют себя фреймворком QP7, можно их поизучать, но как мне кажется они слишком много денег просят и слишком мало дают. Еще один лидер среди местных - NetCat, недавно 3-ю версию выпустили.

Со Smarty без кэширования работать бессмысленно. Скорее всего в системе будет кэширование на уровне ядра/модулей. Обе подсистемы кэширования надо будет как-то подружить между собой. У меня когда-то была такая проблема, тоже пытался Smarty подружить с внутренним кэшированием, в итоге забил на это дело и использовал только внутренее кэширование для системы и шаблонов. Конфликтовали они между собой дико.
Юрий Насретдинов:
Лично мое мнение по поводу большинства CMF, и тем более CMS -- они все очень тяжелые, и не очень-то удобные. Соответственно, я бы рекомендовал писать под каждый проект свой код пхп. Это достаточно удобно, использовать сам язык. И работает это очень шустро.
Vitaminych:
Лично мое мнение по поводу большинства CMF, и тем более CMS -- они все очень тяжелые, и не очень-то удобные. Соответственно, я бы рекомендовал писать под каждый проект свой код пхп. Это достаточно удобно, использовать сам язык. И работает это очень шустро.
Ну сразу бросаться в написание своей системы из-за того, что она по каким-то малозначительным причинам не подошла - это не совсем экономически обосновано. Вы же не будете собирать собственный автомобиль, если не смогли по своим деньгам подобрать нужную модель или комплектацию - проще принять как есть и взять, то что максимально подходит под требования и финансовые возможности. Таким же примером будет программное обеспечение: офисные приложения, графические пакеты, браузеры и т.д. Почему бы тогда и не CMS? Большинство проектов по функционалу схожи, допустим те же корпоративные сайты. Именно для решения таких задач выпускаются коробочные решения типа 1С-Битрикс, NetCat, UMI и прочие местные. С их помощью развернуть хоть какой-то сайт можно в течение 1 часа, нормальный сайт от 1 рабочего дня, ну а серьезные проекты в течение нескольких недель. Разумеется, для этого надо быть специалистом, а не чайником. Писать каждый раз своё или даже использовать свои наработки под корпоративный сайт - это слишком много времени. А время, как мы все знаем, - деньги. И деньги надо экономить. К примеру минимальные редакции отечественных CMS стоят 100-200 баксов, но при этом предлагают довольно обширный функционал: поиск по сайту, управление статичными страницами, регистрация и управление пользователями, каталог товаров, новости, справочники и т.д. До кучи поддержку разработчика, нормальный интерфейс, встроенный API, инструменты кэширования и т.д. Существуют много бесплатных CMS, но они дороги в обслуживании и поддержке, ориентированы на компьюнити, блоги и прочую лабуду, которая имеет минимальное отношение к корпоративным сайтам.

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

Основным типом проектов, под которые коробки могут и не подойти - это сервисные порталы (проекты, предоставляющие одну или несколько сложных услуг), так как в них основную часть проекта все равно придется писать с нуля и использование коробки снимает лишь часть задач вроде авторизации и управления пользователями, кэширования.
Ярмантович В.:
Спасибо, Vitaminych.

Эта тема на forum.dklab.ru