Понятие "многосайтовость" слишком неоднозначное... например для пользователя - это возможность из некого единого интерфейса управлять несколькими его сайтами...
Программист же может подумать, что для него это будет единый набор исполняемых файлов а также все сайты в единой БД, где в таблицах везде есть поле site_id.
пытался делать когда-то такую штуку... геморой не оправданный т.к. во первых всех ресурсы всех сайтов хранятся в одном месте и могут конфликтовать, а еще пытался в одной БД держать данных от нескольких сайтов - вообще мрак %)) фактически гораздо проще с точки зрения разработки держать каждый сайт отдельно, более того даже вендоры не надо делать общими т.к. нюансов может всплыть много и при "неудачном" обновлении одного проекта, может рухнуть вся система...
хотя в прицнипе некоторое подобие "мультидоменности и мультисайтовости" можно сделать, но только за счет конфигураций системы, а не впаенной в неё хардкора ;)
В результате исходные коды проекта могут храниться в сжатом виде в phar формате, а файлы самого сайта будут достаточно лаконичны и просты. Здесь же можно предусмотреть и модульность. Также многое надо уделять работе с консолью т.к. для быстрой разработки надо предусмотреть ряд очень удобных инструментов. Кеширование в таком проекте тоже можно сделать очень продвинутым т.к. он рассчитан на простые сайты, а там можно кешировать буквально все страницы целиком.
Можно сделать проект в котором будет несколько десятков мегабайт вендорного кода и при этом время генерации страницы будет соизмеримо с простым "Hello word" на "чистой" Симфони.
, почти верно ;) сам контейнер хранится в скомпилированном виде в файле /cache/prod/appProdDebugProjectC ontainer.php и обычно он толстенький, но выполняется очень быстро, но как только контейнер загрузится, он отъедает примерно 0.5-1мб памяти - да это накладной расход, но зато нет головняков откуда, что дальше брать и что от чего зависит, всё уже запаковано в нём и можно вытащить простейшим методом get(); соответственно, если от контейнера требуется какой-то сервис, который ни от каких других не зависит, то соберется он тоже очень быстро
А ресурсы в симфони подъедаются на обработчиках событий, например тот же Security сразу же поднимает пачку сервисов и прописывается перед роутингом как файрвол, следовательно все запросы обязательно пройдут через него, а значит будут затрачены ресурсы, но зато такая схема даёт очень удобную и прозрачную систему контроля доступа.
Это почему? При одной и тойже конфигурации разницы не должно быть.
На винде апач работает в режиме Thread Safe, а на линухах Non Thread Safe - в детали я не углублялся, но разница в производительности очень большая. Зато на винде в IIS тоже NTS и производительность почти такая же как на линухах, медленнее всего процентов на 30-50 т.е. совсем не в разы. Также можно прикрутить на винде nginx+fpm вроде тоже адекватно по скорости должно быть...
ksedin, а и еще обрати внимание, если будешь использовать симфони, то на большинстве форумов ты будешь "адепт секты" ;)) а если Yii, Kohana, Codeigniter и т.д., то не будешь ;) в причинах думаю разберешься сам ;)
Laravel 4 - хороший проект и иметь в своём арсенале и ларавел и симфони - это еще лучше! а со временем придёт понимание для каких целей какой инструмент лучше использовать, но знать их нужно достаточно досконально, чтобы оценка была адекватной.
На винде под апачем 200мс - это нормально... на линухе тоже самое будет в 10 раз быстрее т.е. примерно 20мс.
Про "поедание памяти" нужно более предметно поразмыслить... например чтобы написать какой-то функционал "на голом пхп", нужно столько то времени и будет оно потреблять столько то ресурсов, также надо иметь ввиду, что даже ты сам через некоторое время в этот самопис уже не захочешь лезть и уж тем более никого не найдешь для доработки... С другой стороны взвешиваем вычислительные ресурсы проекта на сф2 и оцениваем разницу в деньгах стоимости хостинга, вот эта самая дельта и будет стоимость ковыряния в самописке... Также надо иметь ввиду, что очень часто можно оптимизировать многие вещи, закешировать что-то или вообще завернуть на другой фронт-енд... Хотя действительно, если есть стойкое стремление заставить проект работать на первопопавшемся шареде за 1$ в месяц, то симфони тут вообще не вариант... вопрос больше в том: стоит ли пытаться экономить пару-тройку тысяч рублей в год на хостинге и вкладывать огромное кол-во часов в создание якобы более ресурсо-экономичного проекта...
Шторм с плагином позволяет очень быстро переходить между шаблонами и сервисами, автодополнять всякие методы от сервисов, конфиги и т.д... это повышает производительность разработки в разы и позволяет программисту сосредоточиться на идее, а не на том где что лежит и какие там есть методы...
"Максимальное время" загрузки на холодном старте т.е. когда нету опкеша и сам симфони еще не нагенерировал свои кеши, может быть и 5 и 10 секунд - это вполне нормальная картина, здесь после развёртывания проекта или обновления, следует сразу выполнить
это создаст сразу все симфонические кеши, далее уже надо будет веб-серверу создать опкод кеши, обычно с 2-3 раз он всё кеширует и проект выходит на нормальную производительность... если на странице нет формочек, то отклик 10-20мс и потребление памяти 2-3 мб - это будет нормально. На vps-ке c 1 гигом оперативки выдержит очень приличную нагрузку, впрочем тут можно будет тем же ad и siege пробежаться и увидеть потенциальные возможности проекта на данном сервере.
Что считать "продуктивностью"? ;) Судя по предыдущим вопросам, ты даже phpStorm c симфоническим плугином не применяешь ;) а эти штуки очень сильно повышают продуктивность разработки.
ksedin пишет:
Ведь грамосткость симфонии будет давать нагрузку на сервер, генерирование страницы более чем треть секунды меня не радует.
Всё правильно не надо крутить симфони на апаче под виндой ;) если уж на винде крутится, то лучше использовать IIS и PHP 5.5, а на линухе скорость будет порядка 50мс - а это вполне нормально. Также для продакшина надо не забывать включать кеширование автозагрузчика, доктрины и отключать debug. Еще надо помнить, что акселераторы устроены таким образом, что если сайт долго не запрашивают, то опкод какбы вытесняется их кеша и "холодный" старт будет весьма ресурсоёмкий... а также надо помнить, что у симфони есть свой кеш в котором лежат скомпилированные шаблоны, контнейнер, роутинги и т.д. создание этого кеша на холодном старте тоже много отнимает... В итоге получается, если предприняты элементарные методы оптимизации, то ответ отдаётся достаточно быстро. В качестве примера можешь посмотреть вот на такую цмс-ку https://github[dot]com/Smart-Core/CMS-Sandbox , а вот тут её демка http://do[dot]smart-core[dot]org/ крутится это всё на пхп 5.4, дебиан 7, дигитал океан в Нидерландах, разумеется пхп 5.5 будет и памяти меньше кушать и выполняться быстрее процентов на 20, в ближайшее время разверну где-нибудь 5.5
во во ) вот для этого и надо сначала основы языка изучить а в симфони в частности если в экспериментальных целях что-то менял в папке /vendor/ то сносишь её и выполняешь composer install --prefer-dist
ооо ) вот теперь становится еще понятнее откуда ноги растут тебе нужно изучить язык пхп, а особенно его нововведения в 5.3 и 5.4, для 5.3 могу посоветовать книгу http://www[dot]ozon[dot]ru/context/detail/id/5648968/ обязательно 2011 года, в ней не надо читать главу 17 т.к. сейчас используется Git, а также можно особо не углубляться в 15-ую главу т.к. PEAR не всегда использется, а вот Composer нужно обязательно изучить.
ты зачем-то пишешь 3 двоеточия... в документации такого нет, читай еще и еще, крути и экспериментируй, пока не поймешь замысел... здесь нужно понимать суть.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 406
