Как стать автором
Обновить

Комментарии 90

Заинтересовало. Нужно будет протестировать.
Кинули камень в сторону Yii на графиках :D
Не в коем случае, у систем совершенно разное предназначение. Они вполне могут дополнять друг друга.
Что то мне подсказывает что дял Yii был отключены APC, кэширование и включен режим отладки. Графики, они такие графики.

Вот честно не верю что yii показал столь низкую производительность.
Всего скорее проблема в отсутствии APC, в место него при тестировании был установлен eaccelerator
Судя по скринам — там целая ОС :)
Решил протестировать при помощи ab свою главную страницу, проект на Yii(сейчас его дополнительно долбят порядка 7-8 конкурентных запросов, помимо моего ab). Железка почти как у вас(Intel® Core(TM) i7 CPU 950 @ 3.07GHz).
Document Path:          /
Document Length:        37527 bytes

Concurrency Level:      10
Time taken for tests:   30.000 seconds
Complete requests:      10368
Failed requests:        0
Write errors:           0
Total transferred:      392999040 bytes
HTML transferred:       389079936 bytes
Requests per second:    345.60 [#/sec] (mean)
Time per request:       28.935 [ms] (mean)
Time per request:       2.894 [ms] (mean, across all concurrent requests)
Transfer rate:          12792.84 [Kbytes/sec] received

Правда настроен он по другому (nginx, php-fpm, php-apc,percona5.5). Как то слишком сильно разнятся результаты.
nginx и php-fpm дадут прирост. Мы тестировали демо пример «Блог», использовали apache 2.2. Чтобы убедиться в порядках необходимо протестировать обе платформы на одном и том же железе и настройках. Обращаю внимание, что запускать систему DVelum нужно с настройками production, подробное описание есть в документации Установка и настройка
Вот в том и дело, что свою систему вы запускаете с настройками production, а с какими настройками запускали остальных конкурентов не указываете. Если не готовы выкладывать код с конфигами в посте, то вам бы стоило убрать раздел «Perfomance», как откровенный маркетинг.
У вас есть возможность самостоятельно в этом убедиться. Код примера «блог» доступен как в нашей системе, так и в yii. Это не маркетинг. Если разобраться в причинах такой разницы, то все встанет на свои места. Мы используем подготовленные пакеты кода, количество инструкций include и require минимально. Кроме этого мы кропотливо исправляли медленные места системы при помощи профилирования. Отдельно можно рассмотреть работу с использованием кэширования в memcached, там также есть чему удивиться. Многие подходы, которые мы использовали можно применить к представленным в тесте фреймворкам, тем самым ускорив их, собственно для чего и предназначена платформа.
В таком случае вам определенно стоит выложить использованный код и конфиги для всех обруганных фреймворков, чтобы можно было увидеть как именно вы применяли memcached Yii в частности и в остальных фреймворках в целом, подключали ли yii.php или yiilite.php. Хотелось бы буквально запустить у себя и проверить ваши графики.
Использовался yii.php, memcached не был подключен.
Спасибо, больше у меня к вам вопросов нет.
>Отдельно можно рассмотреть работу с использованием кэширования в memcached, там также есть >чему удивиться

>Использовался yii.php, memcached не был подключен.

Удивится тому что включено кэширование ?=) Революционно!!!
Читайте внимательнее.
Я не думаю что nginx даёт большой прирост, т.к. ab тянет исключительно 1 файл, если бы тянул в перемешку с гифками по полкилобайта, то да, в этих ситуациях апач ведёт себя не очень корректно и то я не думаю что он может забить за 30 секунд 8 гигов памяти.

Я склоняюсь к тому, что на стороне Yii была какая то блокировка(файловая), иначе не возможно объяснить столь низкий результат.
Интересует способ тестирования, да и судя по тому что используется memcache для dvelum, то разница очевидна. Никто не мешает его так же применить и в демоблоге. И тогда уже сравнить результаты.
Нет в случае теста все честно memcached не использовался, вот тесты с memcached:

image
Возможно так и было, мы использовали то, что было предложено разработчиками as is, ничего не трогая.
При должном конфигурировании и правках в демоблоге, yii может показать примерно такие же результаты:
1) активировать мемкэш в конфиге проекта
2) включить кэширование метаданных бд
3) подключить фильтр кэширования(COutputCache) в базовый контроллер
4) перевести сессии на более быстрое хранилище.
+ у меня локально по осчущениям скорость работы того же демоблога осчутимо быстрее. В чем подвох? Я любитель yii и поэтому думаю что необходим тюнинг демоблога перед тестированием, чтоб проекты проверялись в равных условиях.
Да, это было бы интересно, я не спец в тюнинге YII. Подвох от части в этом: habrahabr.ru/post/149853/#comment_5071949
Насколько пригодна для создания приложений со сложной бизнес-логикой, где особо нет структурированных статических страниц, а есть пара десятков контроллеров (модулей?), которые управляют отчётами и формами напрямую на БД не проецирующимися, но активно с ней взаимодействующими? Вычисляемые поля как в базе на основе формы, так и наоборот, сериализованные массивы объектов и прочие подобные извращения?
На основе подобного подхода приходилось выполнять очень сложную систему гос. документооборота, работа над ней как раз и подвела к созданию IDE
А где бизнес-логика хранится? Как реализовали бы задачу типа такой: пользователь заходит в хранилище своих чисел и видит для каждого разложение на простые множители, также может занести множители в форму и их произведение сохранится в базе. То есть в базе хранится произведение, а выводятся и вводятся множители (считаем, что задача разложения решаема за приемлемое время).
Для этого как ни кстати подошел Extjs, взявший на себя отрисовку интерфейса, что позволило отвлечься от шаблонов и заняться непосредственно бизнес логикой.
Поставил минус.

Тексты какие-то у вас очень мутные.
Почему вы взяли Yii и Fat Free?
Почему только их?

>DVelum с популярными CMS
Может это станет для вас неожиданностью но Yii это вообще-то не CMS.

выложите архив того что вы тестировалии, тогда можно будет более менее о чем-то говорить.
По сравнению с CMS так же тестировали, но это разная весовая категория
image
Взяты самые быстрые на наш взгляд фреймворки, Zend был бы незаметен на графике.
Я когда-то очень активно писал под ExtJS, версии 2 и 3, а 4 реально ниасилил, перешел на Bootstrap, иногда только «дерева» не хватает.

Меня взбесила в ExtJS 4 какая-то идея MVC + MVC, причем второй уровень внутри JS

Может быть как раз таким фреймворком его и удобно использовать, но по моему это все уже слишком сложно
А почему на вашем сайте совсем нет демо ни в каком виде, только картинки? (или я не нашел?)
Давно не писал на php, там реально в стайлгайдах учат делать отступы вот так?

    public function upload(array $data, $path)
	{
	          if($data['error'])
	              return false;

	         $result = array(
	             'name'=>'',
	             'path'=>'',
	             'size'=>'',
	             'type'=>''
	         );
	         
	         $name = str_replace(' ','_' , $data['name']);
	         $name =  preg_replace("/[^A-Za-z0-9_\-\.]/i",'',$name);
	    
	        $ext = File::getExt($name);
	        
	        if(!in_array($ext , $this->_config['extensions'])){  
	            return false;
	        }

У PHP толком нет «ванильного» стайл-гайда, есть стайл-гайд как писать код на Си самого PHP, но нет как писать код на PHP.
Ну почему же нет?

Есть несколько достаточно распространенных стандартов (как и для С, в общем).

Вот, например:
Это рекомендации
В том-то и дело, что несколько как и для Си. Нет аналога питоновского PEP 8.
Именно. Частная инициатива.
Для работы из под папки вообще никак не предназначен?
К сожалению нет, не предусмотрено. Это связано с особенностями конструктора интерфейсов.
Очень впечатляет.
Есть какая-то синхронизация моделей фронта с беком? Т.е. для свойств (полей таблицы БД), связей «один ко многим» и т.п. единое место конфигурирования или отдельно?
Единое.
Для меня ExtJS и «производительность» — полярные понятия. Всё, что я видел в жизни, реализованное на ExtJS — безбожно тормозило, любой интерфейс, любая страничка.

> «Задачи, которые решает платформа:
>…
> увеличение производительности разрабатываемых систем.»

По сравнению с чем? Что с чем сравниваем?
Сферический конь в вакууме?
Не поверю, что наличие ExtJS увеличивает производительность по сравнению с plain-PHP кодом, например.
В ExtJS все масса фич для улучшения производительности. Например, сборка в файл и загрузка только нужных компонентов, фреймворка, а не полная загрузка; AJAX-гриды для представления большого количества данных; ленивый рендиринг вьюшек; etc. Другое дело, что не все ими пользуются.
А, ну то есть сравниваем лениво отрендеренную голую страницу с ExtJS и полностью отрендеренную на PHP? А что в лениво отрендеренную будет сваливаться 50 AJAX'ов ещё минуту — это мелочи.
Я не про сравнение, а про:
> Всё, что я видел в жизни, реализованное на ExtJS — безбожно тормозило
Целиком и полностью поддерживаю!
ExtJS сам по себе безбожно тормозит. Спору нет: красиво, наглядно, удобно, но очень-очень медленно.
Если Вам не сложно, напишите примеры торможных решений на ExtJs. Сам его использую и хочется понять, что для Вас означает «безбожно тормозить».
Можно узнать, какие вы видели примеры? Серьезно, очень хотелось бы посмотреть на некоторые рабочие примеры использования ExtJs (мы сами используем). Хочется понять, что для Вас означает «безбожно тормозить».
Не поверю, что наличие ExtJS увеличивает производительность по сравнению с plain-PHP кодом

Ничего, что ExtJS — это клиент-сайд, а PHP — сервер-сайд? Как их можно сравнивать?
По суммарному времени с момента инициации действия пользователем и до получения им результата.
При том же представлении результата и той же реакции на действия пользователя? То есть при том же UI?
При том же сценарии использования.
Вы о компромиссе между отзывчивостью и красотой/удобством/скоростью разработки? Насколько я понимаю тут никто не запрещает «ручками» реализовывать интерфейсы в стиле HTML 2.0, просто есть инструменты для (полу)автоматической генерации интерфейсов на ExtJS.
Нет, я просто рассказал, как считать производительность.
НЛО прилетело и опубликовало эту надпись здесь
И как там у Magento успехи? Давно не читал их исходники.
Подчёркивания в именах свойств — Ваш код застрял в PHP 4.

Из упомянутого выше PSR-1: «This guide intentionally avoids any recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names.» Я лично предпочитаю $under_score.
Видимо, EugeneOZ имел в виду вот это:
Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.
А-а-а, может быть.
Можете показать пример сравнения двух версий «объекта ORM»?
Хороший вопрос. На данный момент у нас нет реализованного функционала под это задачу, но в целом она решаема
               /*
                * предположим, что сравниваем объект "news" c известным нам id,  
                * знаем, что последняя версия 10
                * Вариант 1 Сравнение объекта и его версии
                */
		$vcModel = Model::factory('vc');
		
		$object = new Db_Object('news', $id);	
		$dataBefore = $vcModel->getData('news', $id , 10);
		/*
		 * Нельзя задавать id напрямую
		 */
		unset($dataBefore['id']);

		$object->setValues($dataBefore);		

		var_dump($object->getUpdates());
		
	       /*
                * Вариант 2 Сравнение 2ух версий объекта
                */
		$dataBefore = $vcModel->getData('news', $id , 9);
		$data = $vcModel->getData('news', $id , 10);
		$diff = array(); 
		foreach ($data as $k=>$v){
			if(!isset($dataBefore[$k]) || $dataBefore[$k]!==$v)
				$diff[] = $k;
		}
		var_dump($diff);

Функционал сравнения добавим в следующую версию, спасибо за отзыв
небольшая ошибочка, предположим что последняя версия 11
Про слияние, видимо, даже спрашивать не стоит.

А как вы разрешаете конфликты?
Это версионный контроль данных, какие слияния конфликты вы имеете в виду? Смысл в том, что была некая запись пользователь А внес в нее изменения пользователь B посмотрел какие данные изменил пользователь A.
Если вы имеете в виду функционал блокировки одновременных изменений, на данном этапе он не предусмотрен. Кто последний сохранил тот и прав. Добавить функциональность блокировок вполне реально.
Это версионный контроль данных, какие слияния конфликты вы имеете в виду?

Типичные конфликты класса «пользователи одновременно меняют данные».

Мне просто чем дальше, тем больше кажется, что у вас не «версионный контроль данных», а история изменений. Все-таки, 12-ый год на дворе, VCS уже большие.
Будем исправляться.
Скажите, а что вам мешало взять существующие VCS?
Не доводилось иметь дело сторонними VCS на уровне данных MySQL. Приведите пример такой системы php + mysql, которая бы управляла версиями данных MySQL. Думаю, не мне одному будет полезно изучить это направление.
Не доводилось иметь дело сторонними VCS на уровне данных MySQL.

Не понимаю, о чем вы.

Любая vcs (в том числе и ваша) управляет неким контентом, чаще всего — выраженным в файлах. Соответственно, ваши «версии данных» — это, на самом деле, тоже некоторый файл (и скорее всего, даже текстовый). Собственно, этот файл и кладется в VCS.

Это весьма типичное решение для управления версиями БД, в частности, по схожей технологии работает Database Project в Visual Studio.
Мне кажется мы с вами запутались. Мы говорим о миграции структуры или о версиях данных в БД.
Миграция структуры предусмотрена.
Вы предлагаете сохранять запись из бд в файловую систему?
Так, стоп. Видимо, это я вас неправильно понял.

У вас что версионируется, данные в продуктиве, или результаты разработки?
Ну вот вроде бы и разобрались, мы говорили о разных вещах.
Под версионyым контролем объектов подразумевались непосредственно данные объектов. Их структура лежит и контролируется отдельно, при помощи выбранyой вами VCS
Вроде про миграцию структуры не упомянуто нигде или я пропустил?
Как я понял данная «VCS» реализована не на файлах, а на БД, просто дополняется схема для хранения истории некоторых полей.

Речь не идёт о версионировании схемы, миграциях и т. п., только о данных полей.
Есть механизм синхронизации структуры базы данных, который сверяет конфигурацию и реальную структуру БД, способен обновить структуру базы данных, записать лог SQL запросов. Описание структуры хранится в файлах конфигурации, которые в свою очередь в VCS. Как это связано с одновременной записью данных 2 пользователями мне не совсем понятно.
Все, я вас неправильно понял. Из текста создается ощущение, что у вас есть свой собственный контроль версий разработки.
Нет контроля версий разработки нет, он отдается на откуп разработчику. Единственное, что есть — дополнительный лог операций изменения структуры базы данных.
Просто лог? Откатиться «одним кликом» нельзя?
Откатиться можно следующим образом — откатить файлы конфигурации объектов ORM в своей VCS, в интерфейса запустить синхронизацию структуры. Так же можно воспользоваться бекапом, который можно сделать в интерфейсе управления ORM
Есть проблема контроля версий схемы при разработке приложения с SQL СУБД, а есть проблема контроля версий данных при работе такого приложения. Вы, как я понял, попытались решить обе?
Да, пытаемся. При этом используем не связанные между собой функциональности.
Скачал, просмотрел внутри и снаружи. Очень интересная система. Вот только бы по больше видео о том как использовать систему.
Мы работаем над этим, недавно выпустили первый скринкаст. Документации будет много, на ее написание и перевод необходимо время. Попутно дорабатываем систему с учетом пожеланий и предложений. Например снизили обилие singletone доставшихся по наследству, продумываем локи на одновременное редактирование записей.
>>продумываем локи на одновременное редактирование записей
Кстати, так ли необходимо если использовать транзакции? Ну т.е. если кто-то уже редактирует запись, то вы будете выводить какое-то сообщение, что данные устарели или другой пользователь их редактирует?
Сейчас рассматриваем вариант:
При открытии на редактирование вторым пользователем предупреждать, что запись уже редактируется, возможно некую функцию перехвата лока. Да, при сохранении предупреждать, если запись была изменена кем-то другим, система позволяет определить исходную версию редактируемой записи и были ли изменения другим пользователем.

Остается вопрос на сколько это необходимо конечным пользователям, и не усложнит ли это работу с системой. В комментариях к статье промелькнуло, что нужно, правда в рамках обсуждения другого вопроса.
Выпустили RC1 0.8.6 Первый кандидат на стабильную версию.
Выпустили версию 0.8.8
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории