Pull to refresh

Comments 97

а дубля доков нигде нет?
Вся документация на китайском? Это жесть немного… Англоязычной совсем нету?
Гугл транслей Вам в помощь, хотя и документация ZF на первых порах сгодиться, различия ведь не существенны.
Простите, а на что ссылается звёздочка в заголовке?
На правильное написание слова «фреймворк», видимо!
«самый быстрый» — я все не проверял :)
Тогда звездочку стоило поставить у словосочетания «самый быстрый», т.к. именно его можно поставить под сомнение, а не то, что этот фреймворк может являться не фреймворком.
Что то мне подсказывает, что нет этого фреймворка на наших хостингах. Исходный код не поймешь, если C не знаешь. Достоинство — скорость, все остальное недостатки. Особенно перевод иероглифов в англ., а потом из этого кривого перевода в русский. Представляю на 99% завершенный проект, deadline, а фоеймворк не позволяет сделать какую то мелочь.
я так понял на хабре одни оптимисты (судя по баянистому анекдоту)
Имхо, мертвая тема. Так как небольшое веб приложение, да и даже большое быстрое MVC приложение легко реализовывается без Си(и конечно же без zf sf ci yii и т.д.). Разница между exit('Hello world') и MVC в 2мс максимум с APC конечно. Смысла нет брать фреймворк на Си чтоб потом мучиться если что не так пойдет.
Неплохо было бы указать, что для сборки требуется libpcre3-dev
Чёрт, такой идеи в голову не пришло. Но переписывать в одно лицо хотя бы только Doctrine2 (а в идеале sf2+Twig) не хочеццо. Есть единомышленники?
А смысл? Почему сразу не HipHop PHP использовать?
Не та концепция. Чтобы использовать нужно больше знаний.
Ну тогда смотрите в сторону phc, там как раз новая версия готовится
Можно засунуть в него все классы из Zend_Framework и получившуюся библиотеку подключить в виде расширения?
Для использования HipHop нужно специальным образом подготовить код ко всему прочему.
d2+sf2+twig? на Си? хахаха… лучше забудьте, не реализуете вы это.
разве что нет куда убить несколько лет жизни, а потом понять что это никому не нужно
Один точно не реализую, ернее не буду успевать за развитием оригинала.
А причем оригинал? Есть стабильное API по нему и делать или вы хотите код просто портировать? Если второе то вообще смысла 0 это делать, потому что это прирост производительности хоть и будет но сколько людей нужно чтобы это все поддерживать(10-20), это ведь Си вы там сильно не наабстрагируетесь, КПД от этого чуть ли не нулевой. Короче, что я хотел сказать, такие большие вещи только методом раскрутки писать хорошо, но не наоборот!!! Посмотрите на Java, Scala, C# и их большие либы, это все bootstrapping метод.
Поэтому если у вас нет денег приличных для старта, можете не морочить себе голову, никто переписыванием нескольких тысяч классов не будет заниматься, потому что это глупо, на порядок дешевле купить лишний сервер.
Сегодня хочется верить в чудеса :)
Не знаю архитектуры SF2 + D2 + twig но по сути портировать на Си их очень даже можно. И за сроки порядка пары месяцев. Но не вижу смысла. Нужна скорость — Node.JS, всякие там опкод кэши или хип-хопы… Круто было бы конечно установить свой любимый фреймворк в качестве экстеншена а ежели на сервере не установлен он — то можно и реализацию на PHP заюзать. Хотя профит сомнительный.
«не знаю архитектуры SF2 + D2 + twig настолько, что бы ответить точно*
Вот все меряются пиписьками, а вы возьмите и сравните фреймворки(php) по производительности не «Hello Worl!» а на реальных задачах. Например: Есть 8кк моделей, у каждой свой параметр «крутости», и человек приходя на страницу, играется с фильтром поиска. И чтобы эта система поддерживала дальнейшего расширения(добавление товаров, новых параметров), без переписывания движка, а просто добавить в конфиг файле.
Так вот, какой фреймворк, дас больший профит?
А то от вашей синтетике уже тошно.
8кк сущностей моделей или классов?
А ты видешь в этом разницу?
Ессно. Одно дело выбирать 8кк строк из одной нормализованной таблицы (надеюсь с пагинацией), совсем другое из множества в 8кк таблиц и/или ненормализованных.
А как по твоему ты будешь милионы моделей хранить и их свойства? чем хороша нормализация и горизонталка?
Если у каждой из 8кк моделей есть уникальное свойство, а получать их все нужно в одной выборке, то, имхо, ни одна SQL РСУБД не справится за разумное время (если вообще ограничения позволят создать 8кк таблиц или, хотя бы, 8кк+1 полей в одной таблице) без сериализации уникальных свойств, а с сериализацей фильтрация будет ещё более неразумна. Крутые индексы может и решат проблему выборки по 8кк строк в каждой из которых 8кк-1 полей null, но, имхо, даже фикстуры внести до старта сервиса будет проблемой. Не говоря о динамическом обновлении (и соотвествующей переиндексации).

Чем хороша нормализация — отсутствием избыточных данных (главный минус — скорость выборки). Чем хороша «горизонталка» (денормализованная РБД?) — скоростью выборки (главный минус — необходимость синхронизации записей в таблицах, второй скорость переиндексации).

В общем, имхо, без конкретного ТЗ с оценкой количества и качества операций выборки.вставки.изменения.удаления говорить не о чем. Одно дело, если это счётчик посещаемости, другое, если десятки, а то и тысячи аналитических запросов после единственной транзакции, третье — если миллионы транзакций, но аналитика ра в сутки. 100500-е дело, если на любой запрос время отклика (или реакции — вечно их путаю из-за противоречащих переводов, да и вообще) должно укладываться в 1 мс.
В таких случаях берут нормального программиста и пишут модуль поиска на Си, а не кривокодят на PHP (ну ок, создатели некоторых движков не слушают моих умных советов и все же кривокодят на PHP). По крайней мере, примерно так сделан поиск по людям в том же контакте. И модели тут не нужны, работать с сырыми int'ами куда как быстрее.
Хз. Конечно, надеюсь у вас опыт есть и слова типа «кривокодят» обоснованы. Но, афаик, код, например, бинарного поиска по упорядоченному файлу должен быть одинаков (на уровне алгоритма, конечно) что для PHP, что для чистого (POSIX) Си, к которому у PHP есть прямые биндинги. Да, накладные расходы будут выше, но они не сменят O(log(n)) на O(n). Наверное. Настолько глубокие исследования не проводил, всегда считал, что ф-ция PHP, имеющая прямое соответсвие в Си — это лишь биндинг к Сишной.
Там, где нужен действительно быстрый поиск, поисковый индекс хранится целиком в памяти (ибо ввод-вывод подорвет всю производительность). Си работает быстрее, и те же массивы в PHP занимают во много раз больше места, потому используется Си.

А делать многокритериальный поиск по таблице… ну пока у вас 1000 пользователей/1000 товаров, это вполне допустимо.
Я разве утверждал, что Си медленнее PHP или что-то в этом духе? Я лишь хотел донести, что если код у меня на PHP кривой, то он и на Си будет кривой. Да, работать будет быстрее, но линейно быстрее. Загнётся, скажем не на 1кк записей, а на 10кк.
а смысл такое тестировать если всё равно упрётся в базу, которая упрётся в винт :)
Я уже давно «мечтаю» так попробывать ActiveRecord из Yii переписать). но дальше мечт дело не дошло. Молодцы. Я думаю у многих возникала идейка ченить узкое из фреймворка взять, да переписать в виде экстеншина. А сейчас можно наблюдать реальную эффективность применения этого.
Если уж переписывать, то DataMapper+UoW// IMHO/
Простите, а что показывает диаграмма?
120 чего-то это хорошо, или плохо?
Простите, ознакомьтесь с результатами в табличной форме, которые находятся под диаграммой.
Да конечно.
В таблице написано Connection Times (Количество подключений), видимо чем больше число, тем лучше. Правда странно, что разы измеряются в миллисекундах.

Меня в институте учили ставить размерность и единицы измерения на графиках.
Cреднее время обработки запроса в ms
Но конкретные значение не важны (так как полностью зависят от конкретной конфигурации тестового стенда), главное отношение
Возможно график в инверсированы единицах, нормированный на zf, был бы более нагляден, но менее пригоден для оценки производительности
Я привык, что под такими графиками пишут «Меньше — лучше».
Да и шкалу было бы лучше взять логарифмическую, а то разница между yaf и php не различима.
Так она и в реальности не различимы: 1±.8 vs 2±.8
Я верно понимаю, что это просто Zend в виде PHP Extension? То есть в принципе можно писать любое приложение на Zend Framework и оно уже заранее будет работать если подключена эта библиотека yef?
Вроде ядро только, то есть основные классы включены, а остальные нужно добавлять в проект.
всем известно что ZF еще тот тормоз
но магическое имя Zend заставляет многих
смотреть как кролики в глаза Удава.
у меня диспетчеризация в 4-5 раз осуществляется быстрее чем ZF
17 мс против 85
У вас наверное еще и больше, да?
Я про коммунити.
Ну по правде сказать 17 мс это очень странный показатель. Вы не указали скорость памяти, диска и процессора. А у меня тот же Zend мог бы работать на 17 мс на каком-нибудь супер отмасштабированном в высоту сервере. Другое дело, что ваша поделка не умеет скорее всего генерить штрих коды, а SMTP авторизацию через SSL не поддерживает уж точно, а вот Zend умеет, но лучше его использовать конечно как учебник…
Ну уж если вы мне ответили, то у меня в 17 мсек тоже ZF укладывается, на скромном железе.
Пилить надо уметь.

Но вот и я о том же — нет коммунити — нет фреймворка.
Жалко молодые герои этого не понимают.
полностью согл
нет коммунити — нет фреймворка, так что включайся — будешь третьим goo.gl/nBVtV
что касается если ZF разогнать до 17 мс, то думаю что на отточенном железе у меня это займен менее 3-5х
а мерилось на десктопе (Core2 1.7Ghz ) с обычными IDE дисками без акселлераторов на простых запросах.

что касается умение генерить штрих коды и SMTP авторизацию через SSL — то мне этого не нужно,
а если будет нужно то найду соответствующий класс (ранее использовал отличный класс PHPMailer — очевидно в нем уже есть SSL авторизация, да и для шрихкодирования класс найти не проблема)
Кстати, разместите ваш каркас приложения в отдельный топик в своем блоге. Уже вы нашли аудиторию из 3-5 человек. Возможно кто-то и захочет разрабатывать каркас с вами в дальнейшем…
спасибо,
а сам-то не собираешься развивать его дальше?
а расскажите нам что и где надо подпилить, чтобы было 17 мс?
Профилируйте своё приложение.

Я заменил загрузку огромного application.ini на получение из Redis, плюс заменил многие конструкции на разработки из Evil Rocket Framework.

Ещё старый совет с удалением инклюдов из кода ZF.

Основной оверхед Зенда это роутинг и запускатор (Zend_Application)
Вместо Redis лучше использовать APC (Использование кеширования байкода, я думаю подразумевается)
А в остальном я пользуюсь напильником также
Не, APC/XCache это само собой. В Redis хранится распарсенный конфиг, который у меня обычно гигантский из-за «CDD».

Можно и в APC хранить его, но тогда возникает вопрос при количестве нод > 1
Можете кинуть мне valgrind, я гляну конкретно ваш случай.
вы тоже не путайте реализацию MVC и библиотеки. если мне не нужно генерить штрихкод, то ZF мне не поможет. А если нужно будет — притянуть библиотеку ZF в адекватный фреймворк очень просто.
о, да ладно вам свою поделку с ZF сравнивать.

скажите, а зачем абсолютные пути тута (host.conf.php):
$host_conf = array (
'localhost' => array(
'static' => '/Users/akalend/projects/quickly/static/',
'root' => ' /Users/akalend/projects/quickly/www',
'news' => '/Users/akalend/projects/quickly/static/',
'upload' => '/Users/akalend/tmp/image',

вы их вычислять не умеете?

ps. до этого вроде только github.com/onPHP/onphp-framework С-ext делали
Там и архитектура отсутствует.
к вопросу об архитектуре — сможете ли Вы ответить на воспрос — что это такое?
конечно нет…
иначе бы высказал свое виденье.
сразу видно что один из тех кто много говорит и мало делает…
Вы задали вопрос с заложенной положительной коннотацией.
Я ответил Конечно [Да].

Вы тупой?

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

Как бы, по этому кусочку уже ясно, что шлак.

DRY нарушается 4 раза на 6 строк, про PLA я вообще молчу.
идеи заимствонные из данного шлака используются на одном из самых посещаемых проектов
(7е место в рунете)
спор с Вами бесполезен — Вы — самый настоящий троль
Не всё что вызывает у вас анальную боль, является троллингом.

А где ссылка на проект? Где ссылка на идеи?

Вы — самый настоящий пиздболтун.
проект Лицемер
а идеи см в исходниках
Ссылки.

Проще всего, уйти от ответа, предоставив оппоненту право самому рыться в шлаке.

Ведь никто не будет этим заниматься, и можно объявить себя победителем.
оперативно…
пока писал — уже ответили.
конечно — обосрать всегда проще…

в общем собака зарыта в хитром роутинге
который делается через nginx
это экономит около 25% времени (исключаем запросы к БД)
Вот особого желания срать нет.

Но стоит отвечать за громкие заявления в стиле ZF — буллшит, а вот я…
ну а рыться в шлаке нет необходимости — есть README
README заменяет документацию?
ссылка на проект lice-mer.ru

в моем фреймворке там не представлены (относительно фреймворка проекта) недостающие три компоненты (из-за ненадобности):
— шардинг
— деплоймент
— рендеринг форм

идея последней (рендеринг) — мне не очень нравится, хотя какое-то рациональное зерно есть
шардинг — вещь очень специфическая, скоро начну разрабатывать (есть свои идеи), появился новый проект
ну и соответственно будет время — сделаю деплоймент. Деплоймент — вещь тоже очень специфическая, очень сильно зависит от особенностей проекта.
да и пока на носу более интересные и перспективные проекты
так что скоро появится новая статья
Ладно, теперь для полноты картины — пруфлинк на 7 место. Аппликуха у хомячков известная, но 7-ое место в рунете?

По фактам: я не увидел конкретных объяснений. Ну шардинг, да. Чем он у вас силён?
Чем он лучше ZF? Где документация на него? Или хотя бы ссылка на commented source code?
шардинга у меня нет… если возмусь за новый проект (идут переговоры), то скорее всего он появится.
а в ZF он разве есть? год назад я изучал ZF — его там не было.
Из коробки нет.

Обычно шардит либо БД (mysql proxy, momgo) либо делают хитрый мапредьюсер и функцию выбора Zend_Db по ID.
Мы походу обсуждаем разные вещи.
Я о зрелости, а вы о скорости/функционале/толщине.

За ZF — мощное коммунити, и это главное. Хотя да, я считаю его архитектурным уродом.
echo 'produce time=' .( time() - $this->beginsTime + microtime() - $this->beginmTime) . ' in sec ';


АААААААААААААА!!!
Я удаляюсь из дискуссии, вы победили.
нет! Вы как раз начали дискутировать по делу.
Я думаю, хватит уже засирать комментарии )
ну — там действительно перемудрили с архитектурой
я постарался сделать компактно и оставил то что нужно.
да, возможно мы не поняли друг друга.
но я согласен с Вашим первым замечанием — нет коммунити, нет фреймворка.
Обычно мэпредьюс не делают… (по крайней мере в таких проектах как Мамба, Бадуу, Контакт, Лицемер и еще три малоизвестных...) и mysql_proxy там не используют.
номер шарды определяется на уровне логики Приложения.
Я вот как-то скептически отношусь к мапредьюсам на уровне пыхи, хотя и сам этим грешу, правда по другим причинам — у меня аллергия на вендор-локи.
Only those users with full accounts are able to leave comments. Log in, please.