Тогда звездочку стоило поставить у словосочетания «самый быстрый», т.к. именно его можно поставить под сомнение, а не то, что этот фреймворк может являться не фреймворком.
Что то мне подсказывает, что нет этого фреймворка на наших хостингах. Исходный код не поймешь, если C не знаешь. Достоинство — скорость, все остальное недостатки. Особенно перевод иероглифов в англ., а потом из этого кривого перевода в русский. Представляю на 99% завершенный проект, deadline, а фоеймворк не позволяет сделать какую то мелочь.
Имхо, мертвая тема. Так как небольшое веб приложение, да и даже большое быстрое MVC приложение легко реализовывается без Си(и конечно же без zf sf ci yii и т.д.). Разница между exit('Hello world') и MVC в 2мс максимум с APC конечно. Смысла нет брать фреймворк на Си чтоб потом мучиться если что не так пойдет.
А причем оригинал? Есть стабильное API по нему и делать или вы хотите код просто портировать? Если второе то вообще смысла 0 это делать, потому что это прирост производительности хоть и будет но сколько людей нужно чтобы это все поддерживать(10-20), это ведь Си вы там сильно не наабстрагируетесь, КПД от этого чуть ли не нулевой. Короче, что я хотел сказать, такие большие вещи только методом раскрутки писать хорошо, но не наоборот!!! Посмотрите на Java, Scala, C# и их большие либы, это все bootstrapping метод.
Поэтому если у вас нет денег приличных для старта, можете не морочить себе голову, никто переписыванием нескольких тысяч классов не будет заниматься, потому что это глупо, на порядок дешевле купить лишний сервер.
Не знаю архитектуры SF2 + D2 + twig но по сути портировать на Си их очень даже можно. И за сроки порядка пары месяцев. Но не вижу смысла. Нужна скорость — Node.JS, всякие там опкод кэши или хип-хопы… Круто было бы конечно установить свой любимый фреймворк в качестве экстеншена а ежели на сервере не установлен он — то можно и реализацию на PHP заюзать. Хотя профит сомнительный.
Вот все меряются пиписьками, а вы возьмите и сравните фреймворки(php) по производительности не «Hello Worl!» а на реальных задачах. Например: Есть 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 переписать). но дальше мечт дело не дошло. Молодцы. Я думаю у многих возникала идейка ченить узкое из фреймворка взять, да переписать в виде экстеншина. А сейчас можно наблюдать реальную эффективность применения этого.
Да конечно.
В таблице написано Connection Times (Количество подключений), видимо чем больше число, тем лучше. Правда странно, что разы измеряются в миллисекундах.
Меня в институте учили ставить размерность и единицы измерения на графиках.
Cреднее время обработки запроса в ms
Но конкретные значение не важны (так как полностью зависят от конкретной конфигурации тестового стенда), главное отношение
Возможно график в инверсированы единицах, нормированный на zf, был бы более нагляден, но менее пригоден для оценки производительности
Я верно понимаю, что это просто Zend в виде PHP Extension? То есть в принципе можно писать любое приложение на Zend Framework и оно уже заранее будет работать если подключена эта библиотека yef?
всем известно что ZF еще тот тормоз
но магическое имя Zend заставляет многих
смотреть как кролики в глаза Удава.
у меня диспетчеризация в 4-5 раз осуществляется быстрее чем ZF
17 мс против 85
Ну по правде сказать 17 мс это очень странный показатель. Вы не указали скорость памяти, диска и процессора. А у меня тот же Zend мог бы работать на 17 мс на каком-нибудь супер отмасштабированном в высоту сервере. Другое дело, что ваша поделка не умеет скорее всего генерить штрих коды, а SMTP авторизацию через SSL не поддерживает уж точно, а вот Zend умеет, но лучше его использовать конечно как учебник…
полностью согл
нет коммунити — нет фреймворка, так что включайся — будешь третьим goo.gl/nBVtV
что касается если ZF разогнать до 17 мс, то думаю что на отточенном железе у меня это займен менее 3-5х
а мерилось на десктопе (Core2 1.7Ghz ) с обычными IDE дисками без акселлераторов на простых запросах.
что касается умение генерить штрих коды и SMTP авторизацию через SSL — то мне этого не нужно,
а если будет нужно то найду соответствующий класс (ранее использовал отличный класс PHPMailer — очевидно в нем уже есть SSL авторизация, да и для шрихкодирования класс найти не проблема)
Кстати, разместите ваш каркас приложения в отдельный топик в своем блоге. Уже вы нашли аудиторию из 3-5 человек. Возможно кто-то и захочет разрабатывать каркас с вами в дальнейшем…
вы тоже не путайте реализацию MVC и библиотеки. если мне не нужно генерить штрихкод, то ZF мне не поможет. А если нужно будет — притянуть библиотеку ZF в адекватный фреймворк очень просто.
Вы задали вопрос с заложенной положительной коннотацией.
Я ответил Конечно [Да].
Вы тупой?
Знаете, во многих случаях, я горжусь тем, что мало делаю.
Предпочитаю написать всего одну строчку кода, которая будет стоить дороже вашей школьной поделки.
идеи заимствонные из данного шлака используются на одном из самых посещаемых проектов
(7е место в рунете)
спор с Вами бесполезен — Вы — самый настоящий троль
в моем фреймворке там не представлены (относительно фреймворка проекта) недостающие три компоненты (из-за ненадобности):
— шардинг
— деплоймент
— рендеринг форм
идея последней (рендеринг) — мне не очень нравится, хотя какое-то рациональное зерно есть
шардинг — вещь очень специфическая, скоро начну разрабатывать (есть свои идеи), появился новый проект
ну и соответственно будет время — сделаю деплоймент. Деплоймент — вещь тоже очень специфическая, очень сильно зависит от особенностей проекта.
Ладно, теперь для полноты картины — пруфлинк на 7 место. Аппликуха у хомячков известная, но 7-ое место в рунете?
По фактам: я не увидел конкретных объяснений. Ну шардинг, да. Чем он у вас силён?
Чем он лучше ZF? Где документация на него? Или хотя бы ссылка на commented source code?
шардинга у меня нет… если возмусь за новый проект (идут переговоры), то скорее всего он появится.
а в ZF он разве есть? год назад я изучал ZF — его там не было.
Обычно мэпредьюс не делают… (по крайней мере в таких проектах как Мамба, Бадуу, Контакт, Лицемер и еще три малоизвестных...) и mysql_proxy там не используют.
номер шарды определяется на уровне логики Приложения.
YAF — самый быстрый php фреймворк*