Комментарии 97
Блин, ну и документация там
laruence.com упал (
Вроде нет. Но если что дублируется тут: code.google.com/p/yafphp/
Вся документация на китайском? Это жесть немного… Англоязычной совсем нету?
Гугл транслей Вам в помощь, хотя и документация ZF на первых порах сгодиться, различия ведь не существенны.
Так вот же она: http://www.php.net/manual/en/book.yaf.php
Простите, а на что ссылается звёздочка в заголовке?
Что то мне подсказывает, что нет этого фреймворка на наших хостингах. Исходный код не поймешь, если C не знаешь. Достоинство — скорость, все остальное недостатки. Особенно перевод иероглифов в англ., а потом из этого кривого перевода в русский. Представляю на 99% завершенный проект, deadline, а фоеймворк не позволяет сделать какую то мелочь.
Жесть, хотя бы английский
Имхо, мертвая тема. Так как небольшое веб приложение, да и даже большое быстрое MVC приложение легко реализовывается без Си(и конечно же без zf sf ci yii и т.д.). Разница между exit('Hello world') и MVC в 2мс максимум с APC конечно. Смысла нет брать фреймворк на Си чтоб потом мучиться если что не так пойдет.
Неплохо было бы указать, что для сборки требуется libpcre3-dev
Чёрт, такой идеи в голову не пришло. Но переписывать в одно лицо хотя бы только Doctrine2 (а в идеале sf2+Twig) не хочеццо. Есть единомышленники?
А смысл? Почему сразу не HipHop PHP использовать?
Не та концепция. Чтобы использовать нужно больше знаний.
Ну тогда смотрите в сторону phc, там как раз новая версия готовится
Для использования HipHop нужно специальным образом подготовить код ко всему прочему.
d2+sf2+twig? на Си? хахаха… лучше забудьте, не реализуете вы это.
разве что нет куда убить несколько лет жизни, а потом понять что это никому не нужно
разве что нет куда убить несколько лет жизни, а потом понять что это никому не нужно
Один точно не реализую, ернее не буду успевать за развитием оригинала.
А причем оригинал? Есть стабильное API по нему и делать или вы хотите код просто портировать? Если второе то вообще смысла 0 это делать, потому что это прирост производительности хоть и будет но сколько людей нужно чтобы это все поддерживать(10-20), это ведь Си вы там сильно не наабстрагируетесь, КПД от этого чуть ли не нулевой. Короче, что я хотел сказать, такие большие вещи только методом раскрутки писать хорошо, но не наоборот!!! Посмотрите на Java, Scala, C# и их большие либы, это все bootstrapping метод.
Поэтому если у вас нет денег приличных для старта, можете не морочить себе голову, никто переписыванием нескольких тысяч классов не будет заниматься, потому что это глупо, на порядок дешевле купить лишний сервер.
Поэтому если у вас нет денег приличных для старта, можете не морочить себе голову, никто переписыванием нескольких тысяч классов не будет заниматься, потому что это глупо, на порядок дешевле купить лишний сервер.
Не знаю архитектуры SF2 + D2 + twig но по сути портировать на Си их очень даже можно. И за сроки порядка пары месяцев. Но не вижу смысла. Нужна скорость — Node.JS, всякие там опкод кэши или хип-хопы… Круто было бы конечно установить свой любимый фреймворк в качестве экстеншена а ежели на сервере не установлен он — то можно и реализацию на PHP заюзать. Хотя профит сомнительный.
Вот все меряются пиписьками, а вы возьмите и сравните фреймворки(php) по производительности не «Hello Worl!» а на реальных задачах. Например: Есть 8кк моделей, у каждой свой параметр «крутости», и человек приходя на страницу, играется с фильтром поиска. И чтобы эта система поддерживала дальнейшего расширения(добавление товаров, новых параметров), без переписывания движка, а просто добавить в конфиг файле.
Так вот, какой фреймворк, дас больший профит?
А то от вашей синтетике уже тошно.
Так вот, какой фреймворк, дас больший профит?
А то от вашей синтетике уже тошно.
8кк сущностей моделей или классов?
А ты видешь в этом разницу?
Ессно. Одно дело выбирать 8кк строк из одной нормализованной таблицы (надеюсь с пагинацией), совсем другое из множества в 8кк таблиц и/или ненормализованных.
А как по твоему ты будешь милионы моделей хранить и их свойства? чем хороша нормализация и горизонталка?
Если у каждой из 8кк моделей есть уникальное свойство, а получать их все нужно в одной выборке, то, имхо, ни одна SQL РСУБД не справится за разумное время (если вообще ограничения позволят создать 8кк таблиц или, хотя бы, 8кк+1 полей в одной таблице) без сериализации уникальных свойств, а с сериализацей фильтрация будет ещё более неразумна. Крутые индексы может и решат проблему выборки по 8кк строк в каждой из которых 8кк-1 полей null, но, имхо, даже фикстуры внести до старта сервиса будет проблемой. Не говоря о динамическом обновлении (и соотвествующей переиндексации).
Чем хороша нормализация — отсутствием избыточных данных (главный минус — скорость выборки). Чем хороша «горизонталка» (денормализованная РБД?) — скоростью выборки (главный минус — необходимость синхронизации записей в таблицах, второй скорость переиндексации).
В общем, имхо, без конкретного ТЗ с оценкой количества и качества операций выборки.вставки.изменения.удаления говорить не о чем. Одно дело, если это счётчик посещаемости, другое, если десятки, а то и тысячи аналитических запросов после единственной транзакции, третье — если миллионы транзакций, но аналитика ра в сутки. 100500-е дело, если на любой запрос время отклика (или реакции — вечно их путаю из-за противоречащих переводов, да и вообще) должно укладываться в 1 мс.
Чем хороша нормализация — отсутствием избыточных данных (главный минус — скорость выборки). Чем хороша «горизонталка» (денормализованная РБД?) — скоростью выборки (главный минус — необходимость синхронизации записей в таблицах, второй скорость переиндексации).
В общем, имхо, без конкретного ТЗ с оценкой количества и качества операций выборки.вставки.изменения.удаления говорить не о чем. Одно дело, если это счётчик посещаемости, другое, если десятки, а то и тысячи аналитических запросов после единственной транзакции, третье — если миллионы транзакций, но аналитика ра в сутки. 100500-е дело, если на любой запрос время отклика (или реакции — вечно их путаю из-за противоречащих переводов, да и вообще) должно укладываться в 1 мс.
В таких случаях берут нормального программиста и пишут модуль поиска на Си, а не кривокодят на PHP (ну ок, создатели некоторых движков не слушают моих умных советов и все же кривокодят на PHP). По крайней мере, примерно так сделан поиск по людям в том же контакте. И модели тут не нужны, работать с сырыми int'ами куда как быстрее.
Хз. Конечно, надеюсь у вас опыт есть и слова типа «кривокодят» обоснованы. Но, афаик, код, например, бинарного поиска по упорядоченному файлу должен быть одинаков (на уровне алгоритма, конечно) что для PHP, что для чистого (POSIX) Си, к которому у PHP есть прямые биндинги. Да, накладные расходы будут выше, но они не сменят O(log(n)) на O(n). Наверное. Настолько глубокие исследования не проводил, всегда считал, что ф-ция PHP, имеющая прямое соответсвие в Си — это лишь биндинг к Сишной.
Там, где нужен действительно быстрый поиск, поисковый индекс хранится целиком в памяти (ибо ввод-вывод подорвет всю производительность). Си работает быстрее, и те же массивы в PHP занимают во много раз больше места, потому используется Си.
А делать многокритериальный поиск по таблице… ну пока у вас 1000 пользователей/1000 товаров, это вполне допустимо.
А делать многокритериальный поиск по таблице… ну пока у вас 1000 пользователей/1000 товаров, это вполне допустимо.
а смысл такое тестировать если всё равно упрётся в базу, которая упрётся в винт :)
Я уже давно «мечтаю» так попробывать ActiveRecord из Yii переписать). но дальше мечт дело не дошло. Молодцы. Я думаю у многих возникала идейка ченить узкое из фреймворка взять, да переписать в виде экстеншина. А сейчас можно наблюдать реальную эффективность применения этого.
Простите, а что показывает диаграмма?
120 чего-то это хорошо, или плохо?
120 чего-то это хорошо, или плохо?
Простите, ознакомьтесь с результатами в табличной форме, которые находятся под диаграммой.
Cреднее время обработки запроса в ms
Но конкретные значение не важны (так как полностью зависят от конкретной конфигурации тестового стенда), главное отношение
Возможно график в инверсированы единицах, нормированный на zf, был бы более нагляден, но менее пригоден для оценки производительности
Но конкретные значение не важны (так как полностью зависят от конкретной конфигурации тестового стенда), главное отношение
Возможно график в инверсированы единицах, нормированный на zf, был бы более нагляден, но менее пригоден для оценки производительности
Я верно понимаю, что это просто Zend в виде PHP Extension? То есть в принципе можно писать любое приложение на Zend Framework и оно уже заранее будет работать если подключена эта библиотека yef?
всем известно что ZF еще тот тормоз
но магическое имя Zend заставляет многих
смотреть как кролики в глаза Удава.
у меня диспетчеризация в 4-5 раз осуществляется быстрее чем ZF
17 мс против 85
но магическое имя 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 авторизация, да и для шрихкодирования класс найти не проблема)
нет коммунити — нет фреймворка, так что включайся — будешь третьим goo.gl/nBVtV
что касается если ZF разогнать до 17 мс, то думаю что на отточенном железе у меня это займен менее 3-5х
а мерилось на десктопе (Core2 1.7Ghz ) с обычными IDE дисками без акселлераторов на простых запросах.
что касается умение генерить штрих коды и SMTP авторизацию через SSL — то мне этого не нужно,
а если будет нужно то найду соответствующий класс (ранее использовал отличный класс PHPMailer — очевидно в нем уже есть SSL авторизация, да и для шрихкодирования класс найти не проблема)
Кстати, разместите ваш каркас приложения в отдельный топик в своем блоге. Уже вы нашли аудиторию из 3-5 человек. Возможно кто-то и захочет разрабатывать каркас с вами в дальнейшем…
спасибо,
а сам-то не собираешься развивать его дальше?
а сам-то не собираешься развивать его дальше?
кстати это из него habrahabr.ru/blogs/hi/109050/
советую применить в своих разработках
советую применить в своих разработках
а расскажите нам что и где надо подпилить, чтобы было 17 мс?
Профилируйте своё приложение.
Я заменил загрузку огромного application.ini на получение из Redis, плюс заменил многие конструкции на разработки из Evil Rocket Framework.
Ещё старый совет с удалением инклюдов из кода ZF.
Основной оверхед Зенда это роутинг и запускатор (Zend_Application)
Я заменил загрузку огромного application.ini на получение из Redis, плюс заменил многие конструкции на разработки из Evil Rocket Framework.
Ещё старый совет с удалением инклюдов из кода ZF.
Основной оверхед Зенда это роутинг и запускатор (Zend_Application)
Можете кинуть мне 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 делали
скажите, а зачем абсолютные пути тута (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 я вообще молчу.
Как бы, по этому кусочку уже ясно, что шлак.
DRY нарушается 4 раза на 6 строк, про PLA я вообще молчу.
идеи заимствонные из данного шлака используются на одном из самых посещаемых проектов
(7е место в рунете)
спор с Вами бесполезен — Вы — самый настоящий троль
(7е место в рунете)
спор с Вами бесполезен — Вы — самый настоящий троль
Не всё что вызывает у вас анальную боль, является троллингом.
А где ссылка на проект? Где ссылка на идеи?
Вы — самый настоящийпиздболтун.
А где ссылка на проект? Где ссылка на идеи?
Вы — самый настоящий
проект Лицемер
а идеи см в исходниках
а идеи см в исходниках
Ссылки.
Проще всего, уйти от ответа, предоставив оппоненту право самому рыться в шлаке.
Ведь никто не будет этим заниматься, и можно объявить себя победителем.
Проще всего, уйти от ответа, предоставив оппоненту право самому рыться в шлаке.
Ведь никто не будет этим заниматься, и можно объявить себя победителем.
ссылка на проект lice-mer.ru
в моем фреймворке там не представлены (относительно фреймворка проекта) недостающие три компоненты (из-за ненадобности):
— шардинг
— деплоймент
— рендеринг форм
идея последней (рендеринг) — мне не очень нравится, хотя какое-то рациональное зерно есть
шардинг — вещь очень специфическая, скоро начну разрабатывать (есть свои идеи), появился новый проект
ну и соответственно будет время — сделаю деплоймент. Деплоймент — вещь тоже очень специфическая, очень сильно зависит от особенностей проекта.
в моем фреймворке там не представлены (относительно фреймворка проекта) недостающие три компоненты (из-за ненадобности):
— шардинг
— деплоймент
— рендеринг форм
идея последней (рендеринг) — мне не очень нравится, хотя какое-то рациональное зерно есть
шардинг — вещь очень специфическая, скоро начну разрабатывать (есть свои идеи), появился новый проект
ну и соответственно будет время — сделаю деплоймент. Деплоймент — вещь тоже очень специфическая, очень сильно зависит от особенностей проекта.
да и пока на носу более интересные и перспективные проекты
так что скоро появится новая статья
так что скоро появится новая статья
Ладно, теперь для полноты картины — пруфлинк на 7 место. Аппликуха у хомячков известная, но 7-ое место в рунете?
По фактам: я не увидел конкретных объяснений. Ну шардинг, да. Чем он у вас силён?
Чем он лучше ZF? Где документация на него? Или хотя бы ссылка на commented source code?
По фактам: я не увидел конкретных объяснений. Ну шардинг, да. Чем он у вас силён?
Чем он лучше ZF? Где документация на него? Или хотя бы ссылка на commented source code?
шардинга у меня нет… если возмусь за новый проект (идут переговоры), то скорее всего он появится.
а в ZF он разве есть? год назад я изучал ZF — его там не было.
а в ZF он разве есть? год назад я изучал ZF — его там не было.
Из коробки нет.
Обычно шардит либо БД (mysql proxy, momgo) либо делают хитрый мапредьюсер и функцию выбора Zend_Db по ID.
Обычно шардит либо БД (mysql proxy, momgo) либо делают хитрый мапредьюсер и функцию выбора Zend_Db по ID.
Мы походу обсуждаем разные вещи.
Я о зрелости, а вы о скорости/функционале/толщине.
За ZF — мощное коммунити, и это главное. Хотя да, я считаю его архитектурным уродом.
Я о зрелости, а вы о скорости/функционале/толщине.
За ZF — мощное коммунити, и это главное. Хотя да, я считаю его архитектурным уродом.
Ну а в плане архитектуры:
github.com/akalend/quickly/blob/master/lib/App/Application.php#L17
У вас нет единого интерфейса замеров из соображений экономии?
github.com/akalend/quickly/blob/master/lib/App/Application.php#L17
У вас нет единого интерфейса замеров из соображений экономии?
ну — там действительно перемудрили с архитектурой
я постарался сделать компактно и оставил то что нужно.
я постарался сделать компактно и оставил то что нужно.
да, возможно мы не поняли друг друга.
но я согласен с Вашим первым замечанием — нет коммунити, нет фреймворка.
но я согласен с Вашим первым замечанием — нет коммунити, нет фреймворка.
Обычно мэпредьюс не делают… (по крайней мере в таких проектах как Мамба, Бадуу, Контакт, Лицемер и еще три малоизвестных...) и mysql_proxy там не используют.
номер шарды определяется на уровне логики Приложения.
номер шарды определяется на уровне логики Приложения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
YAF — самый быстрый php фреймворк*