Инфраструктура свободной энциклопедии Wikipedia переведена (http://hhvm.com/blog/7205/wikipedia-on-hhvm) со штатного интерпретатора языка программирования PHP на развиваемую инженерами Facebook виртуальную машину HHVM (http://hhvm.com/) (HipHop Virtual Machine), которая благодаря поддержке JIT-компиляции позволила существенно (https://blog.wikimedia.org/2014/12/29/how-we-made-editing-wi... ускорить выполнение кода движка MediaWiki. В настоящее время все некешируемые операции в Wikipedia, такие как функции редактирования и запросы к API, производятся с использованием HHVM. Процесс миграции Wikipedia на HHVM начался (https://www.mediawiki.org/wiki/HHVM) в марте и продолжался 9 месяцев, за которые совместно с разработчиками из Facebook была проделана большая работа по устранению возникающих проблем, выявляемых в процессе тестового внедрения.
В частности, была выявлена несовместимость реализации класса DOMDocument (http://us3.php.net/manual/en/class.domdocument.php) в HHVM c используемым в MediaWiki кодом для экспорта и импорта данных в формате XML, а также проблемы с расширением для выполнения скриптов на языке Lua. Кроме того, была проделана работа по внесению оптимизаций, рассчитанных на специфику использования MediaWiki, которые были упущены из-за разработки HHVM с оглядкой на виды нагрузки, свойственные Facebook. Например, была обеспечена поддержка JIT при выполнении регулярных выражений и изменён метод отслеживания состояния объектов с заданными дескрукторами, что дополнительно ускорило выполнение кода на 8% и 4%.В итоге, внедрение HHVM позволило в среднем на 45% (почти в два раза!) ускорить обработку динамического контента Wikipedia и значительно снизило нагрузку на CPU, по сравнению с конфигурацией на основе PHP 5.3. Например, время сохранения изменений сократилось в среднем с 6 до 3 сек, а загрузка процессоров на типовом сервере Wikipedia снизилась почти в 6 раз. Отмечается, что по сравнению с PHP 5.3 в актуальной версии PHP 5.6 наблюдается заметный прогресс в области увеличения производительности, поэтому разрыв между PHP 5.6 и HHVM был бы не столь значимым.
<center><a href="http://hhvm.com/wp-content/uploads/2015/01/save-time-0-e1420... src="http://www.opennet.me/opennews/pics_base/0_1420615302.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="http://hhvm.com/wp-content/uploads/2014/12/Screenshot-2014-1... src="http://www.opennet.me/opennews/pics_base/0_1420615329.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Основная причина высокой производительности HHVM заключается в возможности применения JIT-компиляции и динамических оптимизаций, учитывающих особенности выполнения скрипта. В процессе выполнения кода производится определение типов данных и генерация на лету эффективных наборов машинных инструкций, оптимизированных специально для используемых типов. Перед выполнением PHP-скрипты преобразуются в специальное промежуточное абстрактное представление AST (Abstract Syntax Tree), которое затем транслируется в байткод HHBC (HipHop bytecode), который выполняется внутри высокоуровневой виртуальной машины.
URL: https://news.ycombinator.com/item?id=8847934
Новость: http://www.opennet.me/opennews/art.shtml?num=41409
А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было.
Что кстати характерно, она может и не сильно тооще бы стала... у них там в последнее время тоже обертка оберткой погоняет и стеки километровые...Вообще в 2 раза по сравнению с 5.3 - это да, как-то не очень серьезно.
На графике загрузка ЦП уменьшилась с 60% до 10% - в шесть раз, что вполне неплохо
А время выполнения скриптов может ещё хорошо зависить от СУБД, например
> она может и не сильно тооще бы стала...+1. И поддерживать было бы проще, чем устраивать попрыгушки с одной среды исполнения на другую, потом ещё тестить, всё ли на месте.
Пхпшники, по ходу, принялись догонять жабу, пых всё больше и больше стал похож на неё, и по рекомендациям, а то и правилам (писать код не ООП уже стало считаться б-гопротивным), и по дизайну. Всё из неё тащат к себе. Zend Framework – это вообще кошмарная вермишель. Если на то пошло, не лучше ли тогда просто писать на эталоне, к которому они стремятся? Жаба то всяко не хуже.
Жаба-то
> Жаба-тоЖаба - не то!
edited: Не-торт!
Да будто их каждый день устраивают.> Жаба то всяко не хуже
Жаба всяко не лучше, уж кол-во непереносимого никуда г-на на ней написано не меньше, а про скорость, которую обещали значительно улучшить году еще наверное в 2005 даже вспоминать не хочется, там загрузка одной только вм наверное занимает секунд ~дцать.
Даром чтоле гугл слезать с нее собрался.
Мсье, вы когда в последний раз видели Java? Или вы пишите нам из криокамеры?
> Жаба всяко не лучше, уж кол-во непереносимого никуда г-на на ней написано
> не меньше, а про скорость, которую обещали значительно улучшить году еще
> наверное в 2005 даже вспоминать не хочется, там загрузка одной только
> вм наверное занимает секунд ~дцать.Вы не работали с Java всерьез и порете чушь
Эта платформа на сегодня обеспечивает высочайшую производительность
Даже палкой с трех метров трогать не хочуПотому что, дистр какого размера? бинарник какого размера?
а сравните ка это с той же пхпшкой и 15 метровой rpm-койНа рабочем компе 250Кб скриптик (или как эта хрень зовется) прогружается минут пять, а "серьезный" софт на вашей яве, это реальный ретурн ту виндовс 98, речь исключительно о корпоративном секторе.
но это субъективно.
> Вы не работали с Java всерьез и порете чушь
с явой как языком на котором бы что-то писал нет, но во-первых, я не люблю оракель, и не стану ничего писать на яве буть она хоть самой быстрой и масшабируемой средой. А во-вторых, сама идея такой вм в которой бы исполнялось все - уже стухла, имхо, вы можете предерживаться друго мнения, но контейнерная виртуализация позволяет хоть жопой набитый код исполнять, гарантируя при этом безопастность системы и обеспечивая масштабируемость которая яве и не снилась.
Разрабатываете случаем не на PhpStorm? А то он тоже долго грузится, если вы понимаете на что я намекаю..
нет, не разрабатываем, исключительно эксплуатируем и как показывает практика - адекватных решений просто нет, либо монстры на яве к которым не знаешь с какой стороны подойти, которые умеют то, что умеют, а любая автоматизация сверх того обречена на провал, либо свистоперделки, которые умеют все после обработки напильником.
Дружище, абсолютно согласен по поводу Java. Нет, может проггерам и видно, что там "быстрее, выше, сильнее". Но потом шишки от пользователей не им же перепадают. Когда очередной клоун презентует "новое решение" и начальство радостно кричит внедряем, начинается Ж. с этими "энтерпрайз решениям".Так что ООП, переносимость и т.д. - это, конечно, круто. И важно. Но для сферических программистов в вакууме (куда, кстати, авторов с их поделками и хочется отправить после очередного мегарешения).
> Даже палкой с трех метров трогать не хочуТ.е. открываем рот не имея реального опыта работы.
> Потому что, дистр какого размера? бинарник какого размера?
> а сравните ка это с той же пхпшкой и 15 метровой rpm-койКогда ф-ть php достигнет 5% от Java сообщите.
Хотя-бы когда в php появиться зачатки нормальной многопоточности, что-то класса NIO> На рабочем компе 250Кб скриптик (или как эта хрень зовется) прогружается минут
> пять, а "серьезный" софт на вашей яве, это реальный ретурн ту
> виндовс 98Только отчего-то результаты на серверах иные, не такие как Вы рассказали.
Простая замена с ruby на jruby производительность повышает с лету в разы.
ПРо HL задачи вообще говорить не стоит - высоконагруженные системы класса Cassandra на PHP никто писать не будет.> жопой набитый код исполнять, гарантируя при этом безопастность системы и обеспечивая
> масштабируемость которая яве и не снилась.Да, вот что значит перечитать статьи про Docker, когда тело путает одно решение с совершенно иным, при это не осознавая что сравнивает совершенно разные вещи.
Обратите внимание в чем достоинство описанного в статье решения - применяется VM для PHP.
Разрыв шаблона. Потому что VM - это куда больше чем те 1% не главного, которые вы перечислили
Мне совершенно не понятно как контейнерная визуализация решит проблему отсутствия JIT и соот. низкой производительности, когда запросы которые должны выполнятся в пределах 200 мс, а пилятся секундами
И другие 10к. проблем, которые вообще не в той плоскости лежат
Когда функциональность java достигнет хотя-бы 1% от наушников сообщите.
А вообще - давайте строить дома из лопат и копать мидиями.
> Т.е. открываем рот не имея реального опыта работы.Уважаемый, опыт работы может быть разным, ваши супер нагруженные сервера это отличный пример того, как задачи перекладываются с одних больных голов на другие - вместо запила нормальной архитектуры с распределением нагрузки.
> Да, вот что значит перечитать статьи про Docker
Статей по докеру читал может парочку, и его не вспоминал, так как речь не о нем, а о подходе в целом, разница в производительности 2-3 раза у вм не решает ничего, нагрузки растут и будут расти и не можете вы их общитывать сегодя на пхп, завтра на яве. Вместо создания примитивов на нормальном си или даже асме которые можно бы было использовать в любой вм, каждый натирает свой кокос, кто-то яву, кто-то руби, но никто не пишет на чистой яве или руби, все пользуют фреймворки, запихнутые в виртуалки, ну и зачем столько наворотов, тем более, что не решают они ничего. JSON и XML уже решили проблему обмена структурированными данными, о каком таком сверх функционале вы говорите.
> решит проблему отсутствия JIT и соот
А мне вот не понятно как люди живут без регулярных выражений, ну и что живут же.
> запросы которые должны выполнятся в пределах 200 мс
А это вообще отдельная тема, которая к яве и вм какбы не имеет отношения, ну есть это там, и что с того, прикрутить это к пхп абсолютно тривиальная задача.
Могу привести пример ламповых компьютеров, тоже монстры, тоже многое умели, но вымерли как динозавры, которых кстате заменили люди как доминирующий вид, хотя люди не быстрее, не сильнее и совсем ни чем не лучше. Так и ява, и пр. сольются рано или поздно, в угоду луа или js'у.
>> она может и не сильно тооще бы стала...
> +1. И поддерживать было бы проще, чем устраивать попрыгушки с одной среды
> исполнения на другую, потом ещё тестить, всё ли на месте.
> Пхпшники, по ходу, принялись догонять жабу, пых всё больше и больше стал
> похож на неё, и по рекомендациям, а то и правилам (писать
> код не ООП уже стало считаться б-гопротивным), и по дизайну. Всё
> из неё тащат к себе. Zend Framework – это вообще кошмарная
> вермишель. Если на то пошло, не лучше ли тогда просто писать
> на эталоне, к которому они стремятся? Жаба то всяко не хуже.Жаба как эталон дырявости ?
На жабе или не на жабе, на, в любом случае, с самого начала надо писать на нормальном языке.
стартапы редко пишутся на нормальных языках. быстренько набросать на руби сайтик - норма. всё равно 99% года не живет
Ага, её бы тогда вообще не существовало. Нет сайта - нет проблем.
Это как раз общая беда многих проектов. Сначала некие энтузиасты, часто весьма невысокой квалификации берутся что-то делать.
в 99.9% случаев это - никому не нужный хлам.
Но есть небольшой % действительно хороших идей, которые "выстреливают" ... и приходит высокая нагрузка, сложность и т.д.
И "простые" решения становятся дико сложными, все это подпирается вагоном костылей и т.д.
Но с другой стороны - возможность быстро что-то наваять позволяет устроить автопросеивание и снизить планку реализации некой идеи.
а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать на java заменяя одни простые решения на другие.
> а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать
> на java заменяя одни простые решения на другие.Ваше словоблудие не имеет ничего общего с реальным положением дел.
К примеру принятый как стандарт разработки в стартапах и засунутый во все дыры ORM (увеличение скорости разработки - что поделаешь) назвать простой вещью может только человек, который не понимает, какая прослойка стоит за ним.
Равно как и не понимающий, что начиная с определенного уровня нагрузки в ряде участков он должен быть выкинут.
Реальные архитектуры не умерших приложений не имеют ничего общего с "простыми решениями".
Так и так все сложно. или очень сложно.
А на сложные проекты приходят команды, уровень квалификации которых куда выше, чем кажется Вам. И берутся разгребать. И делается это очень успешно, вопреки Вашим сказкам.
Примеров - тьма, как к примеру в Twitter, где после анализа ряд крит. участков переписали на Java, что решило ряд проблем.
Знал бы типичную аудиторию пыхеров и ява гогнокодеров, то не писал бы такой херни. Во-первых, пыхеры слишком тупы чтобы пользоваться какими-то там ORMами, типичный их упровень это портянки из SQL шаблонов.А прослойки между всем типичен как раз для ява кодеров, благо в ява стеке они есть практически для всего и характерный ява кодер вообще почти ничего не знает за пределами API всех этих прослоек - сырой SQL видел только в википедии, протоколы для них это какая-то загадка и тому подобное.
Грубо говоря, пыхеры и ява кодеры это две противоположности дилетанства, одни любят обвешиваться ненужными прослойками, а другие не в состоянии пользоваться даже простым абстрагирующим API.
> А на сложные проекты приходят команды, уровень квалификации которых куда выше
это сильно зависит от бюджетов и области деяетельности. Реально таких специалистов могут себе позволить только крупные компании завязанные на инет бизнес. Даже у них не всегда с кадрами всё так хорошо и в принципе ява кодеров подпускают фрагментально к сложным задачам.
А уже в высокобюджетном энтерпрайз классе работают дилетанты немногим выше уровня пыха.
> а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать
> на java заменяя одни простые решения на другие.Да, в дополнении:
Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются
Вот Вам самый простой пример: у Вас есть задача периодической обработки большого количества входящих запросов, пусть http, без блокирования основных потоков AS, без выноса этих задач куда-то в 3-е штуки.
в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ.
Статусы, синхронизации, блокировки - все работает, если руки не из ж..Теперь возьмем Ruby и любимый RoR ... мало вспоминать про GIL И других вещах, которые буквально ограничивают нас всех при решении задач такого класса.
Могу ли я сделать тоже самое ?
С костылем - да, потратив больше времени. Будет ли оно работает - будет. Только с большими проблемами в плане производительности, из-за нюансов блокировок, невозможности сделать то или иное нормально и т.д.Именно потому, такие вещи как Cassandra на Java, а MongoDB - C++, а Redis - на C
Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. Раньше - для этого был (и есть) erlang/OTP. Обратите внимание - абсолютно разные подходы к построению языка и рантайма, что намекает - не в "особенности" явы или JVM дело, а в том, что всяким рубистам оно не слишком-то надо. Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут. Очереди (которые *MQ), опять же, тоже не вчера придумали. То, что жаба распрстранена - никто не спорит. Но язык убогий, каковым, он, вобщем-то, и планировался.
> Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js.С Go не работал проф., комментировать не имею права.
Про Node...
У Вас недопонимание разницы между понимание асинхронной обработки с псевдо потоками и полноценной многопоточной архитектурой.
Вы пытаетесь мне доказать, что Node.js который по фактически не имеет нормальной многопоточности и инструментов работы с ней будет сопоставим с нормальной многопоточностью в Java при решении одинаковой задачи.
Про то, что в Node.js просто не способен реализовать ряд решений, Вы забываете ?> Раньше - для этого был (и есть) erlang/OTP.
Знаете, Erlang - решение крайне нишевое, но почему Вы его в раньше поставили - ума не приложу. Он весьма активно используется в соот. кругах и теперь, более того - активность его использования растет, причем на глазах.
Erlang - это д-но шедевр для HL. К примеру RabbitMQ - это очень яркий пример.А вот ставить его в один ряд с Node.js не стоило - это платформы разных уровней, т очень большое оскорбление для детища Ericsson
> Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут.
Мы не может реализовать нормальную многопоточность и потому будем искать аргументы почему она не нужна, позиция удобная аж жуть берет ...
Теперь про нагрузку - на ЦПУ относительно да. А вот по памяти ... извините, но fork и послед. события дают такой расход, что.
Даже такие фишки как copy on write не всегда кардинально меняют ситуацию, да и платформенно зависимые они.
Ед. здравый аргумент - многопроц. приложение и сделать проще и работать с процессами отдельными также проще, это факт.> Очереди (которые *MQ), опять же, тоже не вчера придумали.
Ну вот, опять встраиваете костыли которые делают решение оригинальной задачи иным.
Технологически иным, при это добавляя сложность и т.д.
Забавно выходит ... сперва мы ставим некий Node, привязываем еще вагон внешних систем, которые компенсируют ублюдочность самой платформы приложений.
Давайте честными будем перед самим собой - на сегодня для большей части новых проектов ед. критерий - скорость разработки независимо от степени ублюдочности результат.
Но это не повод обзывать более корректно реализованные тех. решения ... каждому -свое.
> Но язык убогий, каковым, он, вобщем-то, и планировался.Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ?
Я намекал, что есть масса способой обработать большой поток запросов. И "нормальные потоки" - только один из них. Там, где вычислений мало, а I/O много - нода вполне на месте. Где летает мало данных, но у них тяжелая обработка - хороши MQ и независимые узлы, что почти автоматом даёт масштабируемость, в отличие от тупой потоковой модели. А можно всё это скомбинировать, достаточно дешево добавив решения, оптимальные для той или иной задачи. Собственно, я ещё не видел больших проектов, где было бы меньше трёх языков задействовано. Бывало, что это были очевидные костыли - пришел кто-то и добавил скрипт на питоне в проект на PHP, а потом его тащат три года. А бывает осознанный выбор решений с учётом их сильных сторон - где-то хорош демон на сях, который предельно экономно расходует память, где-то веб-морда на рубях, для которых разрабатывать удобно, где-то бизнес-логика - хоть и на той же джаве, хоть на Go, хоть на чём.Эрланг "был" - потому что, во-первых, он был первым индустриальным решением, умеющим хорошо работать с подобными задачами, а, во-вторых, он всё же несколько архаичен в синтаксисе и сейчас, когда есть больше альтернатив, можно выбрать что-нибудь более распространённое. С другой стороны - в плане "индустриальности" - то есть надёжности и наличия инструментов деплоя, мониторинга, обновлений и т.п. - он спокойно поспорит с J2EE в любой инкарнации.
Если говорить про оверхед по памяти - не согласен, сорри. Сейчас, по факту, всё больше дело идёт к тому, что каждый поток держит свою копию практически всех данных. Банально потому, что иначе имеем лишнюю связность и рано или позно - проблемы с синхронизацией. Конечно, если форкать JVM или ещё что-то подобное - то оверхед велик. А если нечто, что не тащит такой здоровеный рантайм и без необходимости память не забирает - тут получше ситуация. А что до платформозависимости - по факту сейчас есть только одна мейнстримная платформа, если речь идёт о джаве, пхп или альтернативах - Linux/Intel. И на ней форк крайне дёшев.
> Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ?
А вот тут и кроется непонимание. Экосистема - велика и хорошо проработана. J2EE и тому подобное. Отлаженные фреймворки. туча специалистов и документации. И, собственно, этой проработанностью и берёт - даже там, где можно сделать красивее, часто разумнее и выгоднее пойти по хорошо накатанной дороге и нагородить стандартный тяжелый стек - со спрингом каким-нибудь и тому подобным. А как язык джава по сравнению с тем же C#, C++, Rust, D - примитивна и многословна. И по сравнению с Ruby примитивна. Одно время была надежда, что Scala будет лучше в этом плане, но, насколько я понимаю, на практике всё оказалось не так красиво, как хотелось. Эта примитивность и выливается в монструозные фреймворки с полутора десятками уровней иерархии, которые плохо понимаемы и плохо оптимизируемы.
А JS с нодой - он на отдельную экосистему, как мне кажется, пока не тянет, и как язык лично мне не нравится, но здесь многие не согласятся. Зато на её элемент - вполне. У него есть свои жирные плюсы - то, что один и тот же код умеет работать на клиенте и сервере - иногда очень удобно. Что можно легко перебрасывать людей между фронтэндом и бэкэндом в зависимости от загрузки - тоже. В общем, выбирать надо разумно, а не упираться в одну технологию.
Теперь я понял, что Вы изначально имели ввиду ... жаль, что нам понадобилось так много времени и жаль, что я не понял Вас с самого начала.Если говорить о Scala, то там как мне кажется основная корень проблемы лежит в том, что многие разработчики пытаются на ней разрабатывать в привычном стиле, не используя плюшки.
Т.е. по сути переходя на нее, они остаются на фактически чистой Java.
Это накладывает отпечаток, причем серьезный ... у нас на работе была одна подсистема, которую решили перевести как раз на Scala, Так вот вместо 3-х месяцев понадобилось почти 6. Чтобы люди начали писать именно на ней. И люди не дураки были
К слову обратите внимание на Groovy, он также весьма привлекателен в плане возможностей и по моему мнению более прост в изучении и восприятии.то касается нашей дискуссии о fork, То если поставить граничные условия:
- одна платформа, главное - где работает copy on write
- минимум общих данныхТо в рамках таких допущений можно принять что выгода от скорости разработки позволяет пренебречь некоторыми моментами.
Но в других случаях - не могу согласиться
> Вас есть задача периодической обработки большого количества входящих запросов...
> Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются
> в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ.Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера. Для "большого количества входящих запросов" (tm) тупая схема из начала 90 давно уже не работает. Причём даже для всех скриптовых ЯП делают сложнее обвязки, за исключением быть может пыха.
>> Вас есть задача периодической обработки большого количества входящих запросов...
>> Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются
>> в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ.
> Для "большого количества входящих запросов" (tm) тупая схема из начала
> 90 давно уже не работает.Вообще-то в 90-е самым продвинум откровением был prefork.
Та модель в которой говорю я стала по настоящему массово работоспособной в первой половине 2000-х и до сих пор применяется и будет применятся в приложениях.
Безотносительно того, как каком ЯП написано решение.> Причём даже для всех скриптовых ЯП
> делают сложнее обвязкиПотому что сами платформы не способны обеспечить элементарные инструменты.
Решение задачи передается внешней подсистеме, которая обладает необходимым качеством.
Еще раз разберитесь, что представляют собой технически сегодня многие популярные вещи, разберитесь что такое GIL B т.д.
Т.е. дело как раз в коренной ущербности, где для простоты выкидывается множество функционала. Это оправданно в ряде случаев, но технологически это порождает схемы, при которых в роли стержня выступает убогая обвязка на которую нанизываются внешние системы, которые решают эти задачи.
Но не надо делать вид, что убогость - это мол благо. Надо просто и честно говорить, что к примеру разработчики способные работать с такими вещами стоят денег и их не так много, а типовой конструктор покрывает 99% стартаперских задач> Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера.
Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности, при этом делая вид, что технологически так лучше.
Но Вы делаете вид, что объявляете основу ряда систем "приветом из 90-х"
И вообще конечно, пулы потоков, выносы в отдельный потоки Slow запросов и т.д. - это не для Вас.
Пользуясь Cassandra написанной на Java в роли NoSQL БД Вы конечно будете продолжать орать какая Java плохая и какие там кодеры плохие
Или пользуясь Pum'ой (как по мне - самый лучший Web для Ruby приложений при высокой нагрузке), где применены похожие принципы
Сколько же словестного поноса, ужас...> Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности
Всё верно, только писать нужно правильно, вот так:
> Это степень иллюстрации грамотности лиц, которые используют подходящую архитектуру сервиса вместо применения единственного известного одному гогнокодеру "стандартного" решения
Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема там не в php, а в программистах на нем. Такие на чем угодно напишут crap.
> Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема там
> не в php, а в программистах на нем. Такие на чем
> угодно напишут crap.mediawiki в свое время поразил меня качеством кода, по сравнению с другими php-проектами. Было с чем сравнивать.
> А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было.ага, были бы проблемы куда круче.
>на 45% (почти в два раза!)А разве "2 раза" не равно 200%?
Если сократить среднее время сохранения страницы на 200%, получится машина времени.
Увеличение на 45% - это почти в полтора раза. Но никак не в два.
> Увеличение на 45%Не увеличение, а сокращение (ускорилось)
ЕГЭ-шные математики понабежали...
x-45% = 0,55x
x/(0,55x)=~1.8 - что и есть почти 2
Непонятно чего на человека налетели - написано ведь неправильно:
> ...внедрение HHVM позволило в среднем на 45% (почти в два раза!) ускорить обработку...тоесть скорость обработки возросла на 45% (в 1.45 раза), а не время обработки сократилось на 45% (что должно соответствовать увеличению скорости обработки в 2.(2) раза или на 122.(2)%)
Прошу прощения, конечно, не 2.(2) а 1.(81) и соответственно ускорение на 81.(81)%
А есть сравнение сабжа с opcache
Это вопрос
> Это вопросЭто вопрос
Вопрос ли это вопроса или вопрошение спрашивающего?
Ты задаешь слишком много вопросов.
Написано же, что с 5.6 (где опкеш по дефолту включен), разрыв не такой уж большой.
Уверен, дело явно не в опкеше, ибо ни кто в здравом уме и до этого без опкеша не деплоил.
Сильно сомневаюсь, что в викимедиа наблюдается недостаток здравомыслящих людей.
Значит неверно понял вопрос.
Вообще бенчмарков за последний код была целая куча, гугл в помощь. Обычно получается что HHVM действительно в 1,5-2 раза шустрее чем PHP 5.5-5.6. Однако, с PHP7 (бывший NG) результаты уже не так однозначны - в основном они сопоставимы, местами PHP оказывается быстрее. Так что есть неслабая вероятность, что в будущем Викимедиа мигрируют обратно.
Вот и славно поработали, а то понимаешь "прочтите сообщение от Джимми Уэйлса"
>HHVM (HipHop Virtual Machine)А что ты сделал для хип-хопа в свои годы?
> А что ты сделал для хип-хопа в свои годы?гггг :) Я так понимаю, Богдан Титомир и был основоположником ПХП?
>> А что ты сделал для хип-хопа в свои годы?
> гггг :) Я так понимаю, Богдан Титомир и был основоположником ПХП?А разве это не Децл пел в свое время?
не дождались PHP NG, а могли бы получить тот же двухкратный прирост на "самом обычном" PHP к октябрю 2015 (релиз)
Некоторые вон реактос уже ждут 17 лет. Может быть, ну его, это ожидание? :)
> Некоторые вон реактос уже ждут 17 лет.Да ладно? Зачем? Для чего?.. почему??
Разве они не вымерли(выросли) ещё, так и ждут?
и как там с совместимостью? если в обычном php только и успевают раздавать deprecated (некоторые вещи в рамках 5-й ветки успели и появиться, и прожить, и стать deprecated), то слово -ng не внушает доверия. а вообще - впервые слышу про этот ng. а хип-хоп вроде бы реально работает.
PHP NG тоже уже реально работает, это текущая ветка разработки
релиз планируется к октябрю, я тестировала php-fpm sapi, вордпресс вполне работоспособен,
работает, как и обещано, в 2 раза быстреепроблемы - конфигурация пулов php-fpm не прогружается полностью, ну и расширения пока готовы не все, для меня важен xcache, который к сожалению даже не в PECL'e
Вообщем люди стараются, в первую очередь - Дмитрий Стогов
если что - новости были, на php.net есть страничка в вики (там и про совместимость есть, не все совместимо, расширения так вообще надо серьезно перелопачивать),
не нравится NG, ок. PHP 7.0А вообще хорошо что занялись наконец стандартизацией и повышением производительности, давно пора, а то популярность зашкаливает, а вот качество не дотягивает
xcache - это стороннее расширение, которое никогда не было частью проекта php. В части опкод кэшера он больше не нужен - в ng встроенный opcache. В остальном, может быть, его автор (или кто-то еще) сделает его форк без опкод-кэшера на новом api, по аналогии с apcu.
не надо мне рассказывать,
автор не только не сделает форк без опкод кешера, но и планирует дальше его развивать,
в частности сделать сваппинг на диск (фича была в eaccelerator)не все готовы принять opcache, если честно, я не знаю почему Xuefer не хочет продвинуть xcache в PECL, но бросать или как-либо менять проект он не собирается, он не из тех кто делали APC
а что не так с opcache?
нет свапа на диск -> требуется выделение большого сегмента памяти, сразу под все скрипты желательно
удаление старых скриптов из памяти идет только через сброс всего кеша
нет кеша переменных, соответственно придется тянуть redis,xcache,apcuxcache кстати как кеш переменных, даже в паре с opcache для кода, все равно рвет и memcached и прочие варианты при применении на одном сервере, за счет того что обращение идет к памяти а не по tcp, ну и в xcache есть namespaces (!)
Ну я имею ввиду чисто как опкод-кэшер. Со свопом понятно, хотя у меня даже крупные проекты на Симфони2 прекрасно в память помещаются. Для виртуалок или мини-серверов, согласен, актуально.
> PHP NG тоже уже реально работает, это текущая ветка разработки
> релиз планируется к октябрю, я тестировала php-fpm sapi, вордпресс вполне работоспособен,
> работает, как и обещано, в 2 раза быстрее
> проблемы - конфигурация пулов php-fpm не прогружается полностью, ну и расширения пока
> готовы не все, для меня важен xcache, который к сожалению даже
> не в PECL'e
> Вообщем люди стараются, в первую очередь - Дмитрий СтоговЧто интересно - PHP7 даёт сопоставимую (по крайней мере) производительность при том, что в нём ещё нет JIT. Интересно, что получится когда его всё-таки запилят (а над этим, если судить по рассылке активно работают).
Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип переменной через пару инструкций, плюс частое использование динамических вызовов по строковому имени функций и классов, от jit в джавовском смысле толку будет мало, тут скорее нужен гибрид jit-а с рантаймом, вроде того, как в objective c в плане обмена сообщениями, ну и zval-ы оставить как есть кроме совсем простых случаев.
> Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип переменной
> через пару инструкций, плюс частое использование динамических вызовов по строковому имени
> функций и классов, от jit в джавовском смысле толку будетВ плане типов - уже сто лет как существует type hints и активно используется для аргументов, сейчас аналогично внедряют для указания типа результата. Да, пока только для объектов и массивов, но активно обсуждается и для скаляров. К тому же в том же JS, например, вообще никак нельзя указать тип, однако, это не мешает использовать JIT (сейчас, если не ошибаюсь, все актуальные JS-движки компилируют код в рантайме).
Вызов по строке - крайне редко используется сейчас, т.к. с появляением лямбд, а так же всяких ::class становится почти не нужным.
так уже работоспособно , берем снапшот с git ( master ) и вперед на подвиги :D
не в production естественно
> так уже работоспособно , берем снапшот с git ( master ) и
> вперед на подвиги :D
> не в production естественноPHP, Wordpress - Тяп ляп и в production )
ну у большинства так и есть
http://blog.bnkomi.ru/content/post/13855/vovka_32787390_orig...
> так уже работоспособно , берем снапшот с git ( master ) и вперед на подвиги :Dстоп, а разве JIT уже в мастере? Стогов вроде писал, что пока только работают над этим и NG - это первый шаг. Т.е. у них уже были какие-то наработки в плане just-in-time, но оказалось, что гораздо больший профит можно получить от оптимиизации аллокаций памяти + В рамках того же NG был проделан огромный рефакторинг, на основе которого и планируют добавить JIT. Разве нет? Я что-то пропустил?
ветку phpng уже отправили в master, да
что там с JIT я пока не в курсе, большинство стандартных расширений (включенных в поставку) уже портировали
> ветку phpng уже отправили в master, да
> что там с JIT я пока не в курсе, большинство стандартных расширений
> (включенных в поставку) уже портировалиНу да, про это в курсе. Но нет, JIT там пока нет. Не факт что будет в PHP7, хотя часто проскакивает в интерналсах, что та или иная новая оптимизация нужна для внедрения JIT в будущем.
Совместимость на уровне php-кода - практически 100%, за исключением пары недокументированных хаков, эксплуатирующих особенности старой реализции. Сишные расширения - да, все надо портировать.
хип-хоп маньяки на острие атаки!ps. не взлетит. в смысле, завтра ещё 400 серверов потребуется для нормальной жизни.
> ps. не взлетит.Уже взлетело и развернуто.
>не взлетитчтоб взлетело, попробуй его авиатопливом заправлять. а то на самогоне оно ясен пень не взлетит
этот хихивм поддерживает последние фичи пыха?
больше того он ещё и типизированный PHP поддерживает =)) под названием Hack...
Да. У меня завелся и взлетел портал без проблем. Проблемы возникли со сторонними модулями, типа predis.
>поэтому разрыв между PHP 5.6 и HHVM был бы не столь значимымВместо миграции на новую версию php, они смигрировали куда-то вбок....
а где исходники? хочу под слакварей попробывать
http://hhvm.com/на i686 не работаеть, и не будет.
За 9 месяцев можно было переписать всё на что-то более адекватное, чем php. И никакие костыли типо хип-хопов не понадобились бы. И хип-хоп этот, тоже не панацея. Чудеса он не творит, ибо php во все поля.
Ага, давай, начинай переписывать. Ты сначала посмотри сколько там кода, а потом говори. Там же расширений ещё over 2000
А что поделать.
> А что поделать.Может попробовать перестать нести чушь?
Если бы разрабы вики имели мозги, они сам проект никогда не начали бы на похапэхе, так что вы слишком лестного мнения об их возможностях :) Я б тоже переписал, тем более, что уже понаписана куча веб-движков на всех мыслимых языках.
> время сохранения изменений сократилось в среднем с 6 до 3 секЭээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах. Если 500+ мс на выполнение реквеста -- это уже баг, надо фиксить, обычно меньше 100 должно быть.
Теперь понятно почему Викимедия клянчит деньги на поддержку. Планету греет датацентрами.
Верно ли я понимаю, что у вашего приложения также не меньше 20 миллиардов просмотров в месяц и десятки тысяч хитов в секунду?
> Эээ. Я на жаве пишу веб-приложениябывает, да. ну ничего, со стороны это незаметно обычно: если будешь молчать, окружающие будут считать человеком.
> Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах.+1! Запрос дольше 1 секунды - это уже дикость. Тем более, что у вики структура задачи проще, чем гугл.
>> время сохранения изменений сократилось в среднем с 6 до 3 сек
> Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются
> в миллисекундах. Если 500+ мс на выполнение реквеста -- это уже
> баг, надо фиксить, обычно меньше 100 должно быть.Понимаете, запросы бывают разные, совсем разные ... я займу у Вас 5 мин.
вот бы у меня случай, когда работали над оптимизацией ... ну скажем так - приложения.
И была там подсистема, которая отвечала за генерация аналитики.
Выглядело это так:Клиент (графики на d3.js) <> J2EE приложение <> БД Oracle
Суть в том, что каждый клиент (а их было порядка 300-400 online) должны были получать свои персональные графики. А генерация данных для этих графиков peer client занимала порядка 2c.
Причем это было именно то время, за которое отрабатывала хранимка на БД.
Применять пул потоков для slow запросов такого рода было нецелесообразно, т.к. это непроизводительная трата ресурсов, потому мы добавили еще один backround слой, который для online клиентов в цикле постоянно генерирует данные, а запросы от клиента просто эти данные получают.Так вот это все рассказал к тому, что в реальности slow запросы есть в любой серьезном приложении и их наличие не есть признак плохих разработчиков. Не факт, что их видит клиент ... но ведь операция внесения изменений не простая, согласитесь - это не тупой UPDATE одной записи, там очень серьезная логика ...
древний движок википедии не тормозил на 64киб,
а щас гамно. на андроиде в фирефоксе.
форкать надо ето дело.
> форкать надо ето дело.ДАВНО УЖЕ. Лурк - наше всё. :))
Долго читаю здесь подобные разговоры.Насколько я понял, от качества языка зависит только скорость отладки.
Скорость интерпретатора явно меньше, чем скорость "найтивного" приложения,
поэтому со стороны сервера должно быть нормально скомпилированый сервер(не важно с какого языка). Таким образом, я полагаю, чем больше мы оптимизируем компилятор для сервера, тем больший получим "профит".
Отсюда следует, что надо оптимизировать серверные компиляторы, а интерпретаторами пока пусть пользуются клиенты - типа - "хреновая скорость - куплю машину помощнее".У серверов(потому что это серверы) аппаратная часть поменьше, поэтому компилятор языка написать полегче.
Попытки сделать нормальный сервер на машине с клиентскими возможностями ни к чему хорошему не приводят пока - только к бо-о-ольшим дебатам на opennet и на LOR.
В чём я не прав?
Дополню свое сообщение.
От качества языка зависит, конечно же, не только скорость отладки, но и, возможно, качество сопровождения программы - чем менее популярный язык, тем сопровождение может быть хуже(а может и нет, если она написана достаточно качественно?)Поправлюсь: у серверов(потому что это серверы) аппаратная часть поуже - и если кто-то из своего смартфона на ARM пытается сделать web-сервер, то последнее время он "светится" на opennet, что грустно :(
> Поправлюсь: у серверов(потому что это серверы) аппаратная часть поуже -Шире, причем сильно.
И соседство PowerPC и x86 серверов вполне реальная картина> и если
> кто-то из своего смартфона на ARM пытается сделать web-серверВы не в курсе реального положения дел. ARM сервера - уже реальность.
Начиная от ProLiant m400 до продукции "Рикор"
И продукты набирают популярность, хотя на данный момент ориентация - нишевая.
С силу ряда очевидных причин, не последняя из которых - эффективность энергопотребления
И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем случае в байт-код, а не в инструкции процессора.
> И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем
> случае в байт-код, а не в инструкции процессора.С точки зрения энергосбережения это было бы О-ГО-ГО
потому что "бутылочное горлышко" у серверов уже давно не процессоры, а ПЗУ и сеть ;)
Жесть :) Стоило раз в позитивном ключе заикнуться про жабу...
Давно пора ее переписать на ноде-дж-с
Шило на мыло.
Мне вот интересно, а когда уже напишут граматику MediaWiki на C и вкопилят в Си? Сколько еще ждать? Сколько еще смотреть на то как они кобяняться с PCRE и кучей каких-то костылей?
