JIT компилятор в HHVM, он хорошо проявляет себя когда функции вызываются без перезапуска много раз, что и происходит при запуске HTTP сервера с ReactPHP поверх HHVM.
Не знаю о каком ядре 5.6 идет речь, HHVM поддерживает обе версии одновременно с некоторыми нюансами.
Я говорил о ReactPHP. После прогрева его JIT компилятор показывает очень интересные результаты, которых может не быть при использовании в более традиционном сценарии использования.
Я правда пытаюсь пользоваться Tox, но сборки qTox под Linux не выходят уже пол года (собрать с исходников я тоже не смог из-за многочисленных ошибок и недоговорок), uTox имеет кучу детских болезней вроде несохранения настроек, Antox ни для чего большего чем текстовых сообщений использовать нельзя — аудио напрочь сломано. В итоге позвонить можно только с десктопных клиентов (не всегда) с эхо и низким качеством звука.
Bose QC25 у меня были полтора года. Шумодав хороший, вопросов нет. Но после более качественных устройств звук я бы скорее назвал сносным. Без батареек хоть и работает, но звучит отвратительно.
P.S. Это не считая того, что может отвалиться правое или левое ухо (перестает работать) и расклеиваются фирменные амбушюры от температуры и/или влаги (стоит новый комплект, на секундочку, $35 USD)
Это при условии наличия системы сборки (что по большому счёту верно на сегодняшний день). Но при нативных модулях и HTTP/2 гораздо лучше использовать явные импорты нужных вещей. Это делает зависимости более прозрачными и загрузку более точечной.
P.S. Пока нет нормальной работы с путями и перехватом путей в браузере, чтобы можно было делать алиасы, подсовывать заглушки в тестах и прочее, я пользуюсь RequireJS (и у меня нет полноценной системы сборки, LiveScript пофайлово компилируется с помощью File Watchers во время написания)
Мы избавились от необходимости импортировать каждый используемый модуль по отдельности, создавая огромную import-шапку в каждом файле. Вместо этого один раз импортируем нужные пакеты из imports-файла своего пакета.
Мне кажется, прямым следствием этого будет то, что теперь браузер будет грузить огромную кучу ненужного кода.
Ссылку я кинул для того, чтобы не повторять то, что кто-то уже структурировал в виде статьи. Задумываться над этим мало, нужно иметь решение к вопросам. Но исходя из их сущности решения скорее всего быть не может в общем случае. Если считаете иначе — давайте обсуждать.
JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.
Весьма однозначно сказано что содержимое вполне себе может быть зашифрованным.
Не зависимо от того, используется JWT или другой способ шифрованного хранения сессионных данных, все претензии к подходу из статьи остаются в силе. А первая ссылка на случай если кто-то решит использовать JWT как таковой в принципе.
Ваша реализация, судя по тому что я прочел по диагонали, идеологически похожа, так что вторая статья (и её follow-up) весьма применима и для вашего случая.
А модуль-то вам зачем О_о? Есть же php-fpm.
JIT компилятор в HHVM, он хорошо проявляет себя когда функции вызываются без перезапуска много раз, что и происходит при запуске HTTP сервера с ReactPHP поверх HHVM.
Не знаю о каком ядре 5.6 идет речь, HHVM поддерживает обе версии одновременно с некоторыми нюансами.
Я говорил о ReactPHP. После прогрева его JIT компилятор показывает очень интересные результаты, которых может не быть при использовании в более традиционном сценарии использования.
И без HHVM. ReactPHP под HHVM показывает совсем другие цифры:)
Сравнение производительности на Apache2? Почему не Nginx?
Я правда пытаюсь пользоваться Tox, но сборки qTox под Linux не выходят уже пол года (собрать с исходников я тоже не смог из-за многочисленных ошибок и недоговорок), uTox имеет кучу детских болезней вроде несохранения настроек, Antox ни для чего большего чем текстовых сообщений использовать нельзя — аудио напрочь сломано. В итоге позвонить можно только с десктопных клиентов (не всегда) с эхо и низким качеством звука.
Для дороги где важна компактность и шумоизоляция приобрел ETYMOTIC HF3.
Для домашнего прослушивания взял Sennheiser HD250 Linear II.
По моему мнению обе модели хоть и разные, но звучат гораздо лучше и стоят при этом вместе дешевле за Bose QC25.
Bose QC25 у меня были полтора года. Шумодав хороший, вопросов нет. Но после более качественных устройств звук я бы скорее назвал сносным. Без батареек хоть и работает, но звучит отвратительно.
P.S. Это не считая того, что может отвалиться правое или левое ухо (перестает работать) и расклеиваются фирменные амбушюры от температуры и/или влаги (стоит новый комплект, на секундочку, $35 USD)
Это при условии наличия системы сборки (что по большому счёту верно на сегодняшний день). Но при нативных модулях и HTTP/2 гораздо лучше использовать явные импорты нужных вещей. Это делает зависимости более прозрачными и загрузку более точечной.
P.S. Пока нет нормальной работы с путями и перехватом путей в браузере, чтобы можно было делать алиасы, подсовывать заглушки в тестах и прочее, я пользуюсь RequireJS (и у меня нет полноценной системы сборки, LiveScript пофайлово компилируется с помощью File Watchers во время написания)
Мне кажется, прямым следствием этого будет то, что теперь браузер будет грузить огромную кучу ненужного кода.
Более того, в другие направления наоборот набирают новых людей
30-60% разработчиков Unity 8, зачем такой желтый заголовок?
Голословно — не правильно. А если аргументировано, указывая на фундаментальные ошибки и заблуждения, то вполне себе можно и нужно.
Ссылку я кинул для того, чтобы не повторять то, что кто-то уже структурировал в виде статьи. Задумываться над этим мало, нужно иметь решение к вопросам. Но исходя из их сущности решения скорее всего быть не может в общем случае. Если считаете иначе — давайте обсуждать.
Опять таки, чтобы не повторяться, рекомендую прочесть саркастический ответ на часто встречаемые контр-аргументы (он упомянут в шапке той статьи, если пропустили): http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/
Вы Abstract читали (первый параграф)?:
Весьма однозначно сказано что содержимое вполне себе может быть зашифрованным.
Не обязательно
Тогда будьте добры, уточните что во второй статье относится исключительно к JWT и не релевантно данной статье.
Вы правда читали статью по второй ссылке?
Не зависимо от того, используется JWT или другой способ шифрованного хранения сессионных данных, все претензии к подходу из статьи остаются в силе. А первая ссылка на случай если кто-то решит использовать JWT как таковой в принципе.
То, что вы придумали обычно реализуют через JWT, для чего есть множество библиотек, в том числе на PHP.
А ещё есть статьи где популярно объясняется почему реализация сессий на клиенте это плохая идея в общем и с использованием JWT в частности:
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
Ваша реализация, судя по тому что я прочел по диагонали, идеологически похожа, так что вторая статья (и её follow-up) весьма применима и для вашего случая.