Я же мысль развивал, не для того что бы сказать, что это не рабочий инструмент. А хотел объяснить, что часто и густо на рабочих проектах оверхеды сводят на нет подобные реализации. Сам ReactPHP не течет, но он же и не рабочее приложение, а только обертка по сути. Я в свое время убивал уйму времени на подобные способы ускорения работы РНР. Потом, заморочился и сделал связку Mongoose+РНР, первые тесты тоже были очень красивые, но когда включил рабочее приложение все производительность исчезла и осталось порядка 10% прироста, что для меня было не приемлемо.
Для Casus, без пулов вы очень быстро уложите любую БД при нормальной нагрузке. Нельзя на один конект к БД повесить все что у вас есть, максимум что вы сможете выделить в этом варианте — это одно ядро (или поток), много ли оно вам даст производительности? Пул для того и нужен чтобы эффективно нагружать машину и в зависимости от ее тех. характеристик — количества ядер и памяти. И то что «Сессия, в Symfony, привязана к запросу» никак не поможет с тем что я перечислял для асинхронного режима.
Для nikita2206, такой подход оправдан если делаем только одни SELECTты, но тогда следом вопрос, а зачем их вообще делать если можно тупо кинуть в кеш? Если будем использовать INSERT + SELECT уже нарвемся на дикие очереди на процессоре. Нельзя вот так просто дать все на откуп быстрым воркерам. Я в своей практике работал с проектом, где к БД было порядком 70-80 тыс запросов в минуту (днем), и могу сказать, что приложение работало банально под связкой mod_php (apache) и вся проблема была только в распределении нагрузки на БД.
П.С.: Я не предвзят, просто опыт работы с решением подобных проблем налаживает свой отпечаток.
Ну начнем с того, что про работу с функциями типа LAST_INSERT_ID() можно забыть. Транзакции, лок таблиц, использование переменных сессии и т.д. Асинхронные запросы это конечно хорошо, но это не решает проблемы выделения отдельных конектов к БД для их работы, что влечет за собой дальше использование пулов и работы с ними. Я все же убежден что лучше хороший кеш, чем быстрая БД (SQL), если мы говорим про выдачу данных, а не их обработку. И еще добавлю, не знаю как ReactPHP, но всякое использование постоянно загруженного приложения в РНР вело к проблемам с памятью, если не брать в учет примеры типа «Hello World». Возможно в последних версиях этого стало меньше, но последний раз когда я сталкивался с подобными задачами в РНР 5.3 с этим были большие проблемы, очень большую роль играет, то какая архитектура приложения.
А в чем странность решения nginx+memcache? Такая связка очень хорошо себя оправдывает для простой статики, для картинок так и подавно. Ну а про varnish, это как бы и не кеш в широком понятии, т.к. «it is a reverse http proxy that caches». Пока мне хватало связки haproxy ->nginx->memcache. Можно конечно воткнуть varnish после haproxy, но это несет дополнительные расходы на железо.
А проблему работы скрипта с базами данных (SQL) аккуратно пропустили в статье. Даже если все повесить на persistent connect это почти не решит проблемы накладных расходов. После чего вся скорость и преимущества ReactPHP и других решений меркнет перед жуткими мыслями, как переписать код чтобы он вообще начал работать. Панацей по сути могут быть только кеши, аля nginx+memcache, где РНР используется только тогда, когда надо закинуть данные в кеш. И даже если страницы динамичные, то 80% страницы статика и только небольшая часть ее меняется, что тоже решается не сложными плясками вокруг кеша.
Для разработки под Smart TV, все предельно просто: developer.samsung.com/smarttv
Дефолтная IDE используется Eclipse. В комплект SDK входит так же эмулятор самого Smart TV и ДУ.
Разработка самих приложений на HTML+JS.
Есть достаточное количество хороших примеров.
Вообщем по своему опыту за 1-2 дня разобрался, еще через 2 дня уже готовое приложение.
Было бы хорошо, тот же тест с включенным АРС + пару простых SELECT запросов на persistent конекте.
Разница в тестах будет минимальной, в пределах 2-4%.
Выносить код на С имеет смысл, если у вас производится много логический и мат. операций, в остальном смысл перехода на компиленый фреймворк сводится на нет.
Это видимо скоро и хотят проверить, передав на станцию атомные часы для проведения исследований. Странно, что этого раньше не сделали. В физике я не силен, но на сколько знаю скорость источника и скорость движения от источника не складывается и это доказали еще в середине прошлого века. Пока что вопросов больше чем ответов.
И нифига это не прикольно, то что гугл, когда захочет будет смотреть кого угодно это и так понятно. Но к ним еще примкнет не хилое сообщество хакеров, которые думаю разберутся, как это дело еще и перехватывать.
Жаль (( а так не хотелось на FF возвращаться.
Для Casus, без пулов вы очень быстро уложите любую БД при нормальной нагрузке. Нельзя на один конект к БД повесить все что у вас есть, максимум что вы сможете выделить в этом варианте — это одно ядро (или поток), много ли оно вам даст производительности? Пул для того и нужен чтобы эффективно нагружать машину и в зависимости от ее тех. характеристик — количества ядер и памяти. И то что «Сессия, в Symfony, привязана к запросу» никак не поможет с тем что я перечислял для асинхронного режима.
Для nikita2206, такой подход оправдан если делаем только одни SELECTты, но тогда следом вопрос, а зачем их вообще делать если можно тупо кинуть в кеш? Если будем использовать INSERT + SELECT уже нарвемся на дикие очереди на процессоре. Нельзя вот так просто дать все на откуп быстрым воркерам. Я в своей практике работал с проектом, где к БД было порядком 70-80 тыс запросов в минуту (днем), и могу сказать, что приложение работало банально под связкой mod_php (apache) и вся проблема была только в распределении нагрузки на БД.
П.С.: Я не предвзят, просто опыт работы с решением подобных проблем налаживает свой отпечаток.
П.С,: Минусерам привет, вот поэтому пропадает желание писать на хабре.
Дефолтная IDE используется Eclipse. В комплект SDK входит так же эмулятор самого Smart TV и ДУ.
Разработка самих приложений на HTML+JS.
Есть достаточное количество хороших примеров.
Вообщем по своему опыту за 1-2 дня разобрался, еще через 2 дня уже готовое приложение.
Все время получаю монтирование read-only.
Разница в тестах будет минимальной, в пределах 2-4%.
Выносить код на С имеет смысл, если у вас производится много логический и мат. операций, в остальном смысл перехода на компиленый фреймворк сводится на нет.
Жаль (( а так не хотелось на FF возвращаться.