The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект Wikipedia перешёл на использование HHVM для выполнения PHP-кода

07.01.2015 10:17

Инфраструктура свободной энциклопедии Wikipedia переведена со штатного интерпретатора языка программирования PHP на развиваемую инженерами Facebook виртуальную машину HHVM (HipHop Virtual Machine), которая благодаря поддержке JIT-компиляции позволила существенно ускорить выполнение кода движка MediaWiki. В настоящее время все некешируемые операции в Wikipedia, такие как запросы к API, функции редактирования, показ кастомизированного интерфейса для зарегистрированных пользователей, производятся с использованием HHVM. Процесс миграции Wikipedia на HHVM начался в марте и продолжался 9 месяцев, за которые совместно с разработчиками из Facebook была проделана большая работа по устранению возникающих проблем, выявляемых в процессе тестового внедрения.

В частности, была выявлена несовместимость реализации класса DOMDocument в HHVM c используемым в MediaWiki кодом для экспорта и импорта данных в формате XML, а также проблемы с расширением для выполнения скриптов на языке Lua. Кроме того, была проделана работа по внесению оптимизаций, рассчитанных на специфику использования MediaWiki, которые были упущены из-за разработки HHVM с оглядкой на виды нагрузки, свойственные Facebook. Например, была обеспечена поддержка JIT при выполнении регулярных выражений и изменён метод отслеживания состояния объектов с заданными деструкторами, что дополнительно ускорило выполнение кода на 8% и 4%. С другой стороны, предоставляемые проектом HHVM инструменты анализа кода позволили выявить и устранить ранее не замеченные узкие места в коде MediaWiki, а также оценить корректность использования типов данных.

В итоге, внедрение HHVM позволило почти в два раза уменьшить время обработки динамического контента Wikipedia и значительно снизило нагрузку на CPU, по сравнению с конфигурацией на основе PHP 5.3. Например, время сохранения изменений сократилось в среднем с 6 до 3 сек, время выдачи страницы для зарегистрированных пользователей уменьшилось с 1.3 до 0.9 сек, а загрузка процессоров на типовом сервере Wikipedia снизилась в 5-6 раз. Отмечается, что по сравнению с PHP 5.3 в актуальной версии PHP 5.6 наблюдается заметный прогресс в области увеличения производительности, поэтому разрыв между PHP 5.6 и HHVM был бы не столь значимым.

Основная причина высокой производительности HHVM заключается в возможности применения JIT-компиляции и динамических оптимизаций, учитывающих особенности выполнения скрипта. В процессе выполнения кода производится определение типов данных и генерация на лету эффективных наборов машинных инструкций, оптимизированных специально для используемых типов. Перед выполнением PHP-скрипты преобразуются в специальное промежуточное абстрактное представление AST (Abstract Syntax Tree), которое затем транслируется в байткод HHBC (HipHop bytecode), который выполняется внутри высокоуровневой виртуальной машины.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Facebook представил Hack, вариант языка PHP со статической типизацией
  3. OpenNews: Facebook анонсировал виртуальную машину HipHop и JIT-компилятор для языка PHP
  4. OpenNews: В Wikipedia добавлена поддержка разработки шаблонов на языке Lua
  5. OpenNews: Основная инфраструктура Wikipedia переведена с MySQL на MariaDB
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41409-hhvm
Ключевые слова: hhvm, php, wikipedia
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (107) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Ящ (ok), 11:10, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было.
     
     
  • 2.3, vitalif (ok), 11:19, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что кстати характерно, она может и не сильно тооще бы стала... у них там в последнее время тоже обертка оберткой погоняет и стеки километровые...

    Вообще в 2 раза по сравнению с 5.3 - это да, как-то не очень серьезно.

     
     
  • 3.9, Нанобот (ok), 11:59, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На графике загрузка ЦП уменьшилась с 60% до 10% - в шесть раз, что вполне неплохо
    А время выполнения скриптов может ещё хорошо зависить от СУБД, например
     
  • 3.10, Ящ (ok), 12:01, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > она может и не сильно тооще бы стала...

    +1. И поддерживать было бы проще, чем устраивать попрыгушки с одной среды исполнения на другую, потом ещё тестить, всё ли на месте.
    Пхпшники, по ходу, принялись догонять жабу, пых всё больше и больше стал похож на неё, и по рекомендациям, а то и правилам (писать код не ООП уже стало считаться б-гопротивным), и по дизайну. Всё из неё тащат к себе. Zend Framework – это вообще кошмарная вермишель. Если на то пошло, не лучше ли тогда просто писать на эталоне, к которому они стремятся? Жаба то всяко не хуже.

     
     
  • 4.31, Grammar_Nazi (?), 15:51, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Жаба-то
     
     
  • 5.85, Аноним (-), 00:43, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Жаба-то

    Жаба - не то!

     
     
  • 6.101, count0krsk (ok), 20:27, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    edited: Не-торт!
     
  • 4.33, cmp (ok), 16:24, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да будто их каждый день устраивают.

    > Жаба то всяко не хуже

    Жаба всяко не лучше, уж кол-во непереносимого никуда г-на на ней написано не меньше, а про скорость, которую обещали значительно улучшить году еще наверное в 2005 даже вспоминать не хочется, там загрузка одной только вм наверное занимает секунд ~дцать.

    Даром чтоле гугл слезать с нее собрался.

     
     
  • 5.38, Аноним (-), 18:36, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Мсье, вы когда в последний раз видели Java? Или вы пишите нам из криокамеры?
     
  • 5.41, edwin3d (ok), 18:53, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Жаба всяко не лучше, уж кол-во непереносимого никуда г-на на ней написано
    > не меньше, а про скорость, которую обещали значительно улучшить году еще
    > наверное в 2005 даже вспоминать не хочется, там загрузка одной только
    > вм наверное занимает секунд ~дцать.

    Вы не работали с Java всерьез и порете чушь
    Эта платформа на сегодня обеспечивает высочайшую производительность

     
     
  • 6.52, cmp (ok), 22:02, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Даже палкой с трех метров трогать не хочу Потому что, дистр какого размера бина... большой текст свёрнут, показать
     
     
  • 7.54, vn971 (ok), 00:43, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Разрабатываете случаем не на PhpStorm? А то он тоже долго грузится, если вы понимаете на что я намекаю..
     
     
  • 8.56, cmp (ok), 04:06, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, не разрабатываем, исключительно эксплуатируем и как показывает практика - а... текст свёрнут, показать
     
     
  • 9.109, Аноним (-), 10:16, 12/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Дружище, абсолютно согласен по поводу Java Нет, может проггерам и видно, что та... текст свёрнут, показать
     
  • 7.61, edwin3d (ok), 08:40, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Т е открываем рот не имея реального опыта работы Когда ф-ть php достигнет 5 о... большой текст свёрнут, показать
     
     
  • 8.73, рубин (?), 13:12, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда функциональность java достигнет хотя-бы 1 от наушников сообщите А вообще... текст свёрнут, показать
     
  • 8.77, cmp (ok), 16:01, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Уважаемый, опыт работы может быть разным, ваши супер нагруженные сервера это отл... большой текст свёрнут, показать
     
  • 4.110, tor (??), 14:15, 12/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> она может и не сильно тооще бы стала...
    > +1. И поддерживать было бы проще, чем устраивать попрыгушки с одной среды
    > исполнения на другую, потом ещё тестить, всё ли на месте.
    > Пхпшники, по ходу, принялись догонять жабу, пых всё больше и больше стал
    > похож на неё, и по рекомендациям, а то и правилам (писать
    > код не ООП уже стало считаться б-гопротивным), и по дизайну. Всё
    > из неё тащат к себе. Zend Framework – это вообще кошмарная
    > вермишель. Если на то пошло, не лучше ли тогда просто писать
    > на эталоне, к которому они стремятся? Жаба то всяко не хуже.

    Жаба как эталон дырявости ?

     
  • 2.7, YetAnotherOnanym (ok), 11:51, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    На жабе или не на жабе, на, в любом случае, с самого начала надо писать на нормальном языке.
     
     
  • 3.49, Гаражник (?), 20:44, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    стартапы редко пишутся на нормальных языках. быстренько набросать на руби сайтик - норма. всё равно 99% года не живет
     
  • 2.22, Аноним (-), 14:00, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ага, её бы тогда вообще не существовало. Нет сайта - нет проблем.
     
  • 2.40, edwin3d (ok), 18:51, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это как раз общая беда многих проектов. Сначала некие энтузиасты, часто весьма невысокой квалификации берутся что-то делать.
    в 99.9% случаев это - никому не нужный хлам.
    Но есть небольшой % действительно хороших идей, которые "выстреливают" ... и приходит высокая нагрузка, сложность и т.д.
    И "простые" решения становятся дико сложными, все это подпирается вагоном костылей и т.д.
    Но с другой стороны - возможность быстро что-то наваять позволяет устроить автопросеивание и снизить планку реализации некой идеи.

     
     
  • 3.48, all_glory_to_the_hypnotoad (ok), 20:24, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать на java заменяя одни простые решения на другие.
     
     
  • 4.50, edwin3d (ok), 21:41, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ваше словоблудие не имеет ничего общего с реальным положением дел К примеру при... большой текст свёрнут, показать
     
     
  • 5.80, all_glory_to_the_hypnotoad (ok), 17:24, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Знал бы типичную аудиторию пыхеров и ява гогнокодеров, то не писал бы такой херн... большой текст свёрнут, показать
     
  • 4.51, edwin3d (ok), 21:59, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, в дополнении Java позволяет делать такие вещи, про которые в других платфор... большой текст свёрнут, показать
     
     
  • 5.75, Crazy Alex (ok), 14:05, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. Раньше - для этого был (и есть) erlang/OTP. Обратите внимание - абсолютно разные подходы к построению языка и рантайма, что намекает - не в "особенности" явы или JVM дело, а в том, что всяким рубистам оно не слишком-то надо. Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут. Очереди (которые *MQ), опять же, тоже не вчера придумали. То, что жаба распрстранена - никто не спорит. Но язык убогий, каковым, он,  вобщем-то, и планировался.
     
     
  • 6.76, edwin3d (ok), 14:53, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    С Go не работал проф , комментировать не имею права Про Node У Вас недопо... большой текст свёрнут, показать
     
     
  • 7.83, Crazy Alex (ok), 19:31, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я намекал, что есть масса способой обработать большой поток запросов И нормаль... большой текст свёрнут, показать
     
     
  • 8.91, edwin3d (ok), 10:26, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Теперь я понял, что Вы изначально имели ввиду жаль, что нам понадобилось так... большой текст свёрнут, показать
     
  • 5.84, all_glory_to_the_hypnotoad (ok), 22:30, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Вас есть задача периодической обработки большого количества входящих запросов...
    > Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются
    > в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ.

    Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера. Для "большого количества входящих запросов" (tm) тупая схема из начала 90 давно уже не работает. Причём даже для всех скриптовых ЯП делают сложнее обвязки, за исключением быть может пыха.

     
     
  • 6.90, edwin3d (ok), 10:13, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вообще-то в 90-е самым продвинум откровением был prefork Та модель в которой го... большой текст свёрнут, показать
     
     
  • 7.105, all_glory_to_the_hypnotoad (ok), 22:15, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Сколько же словестного поноса, ужас...

    > Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности

    Всё верно, только писать нужно правильно, вот так:

    > Это степень иллюстрации грамотности лиц, которые используют подходящую архитектуру сервиса вместо применения единственного известного одному гогнокодеру "стандартного" решения

     
  • 2.44, Аноним (-), 19:48, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема там не в php, а в программистах на нем. Такие на чем угодно напишут crap.
     
     
  • 3.68, dev (??), 12:04, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема там
    > не в php, а в программистах на нем. Такие на чем
    > угодно напишут crap.

    mediawiki в свое время поразил меня качеством кода, по сравнению с другими php-проектами. Было с чем сравнивать.

     
  • 2.47, all_glory_to_the_hypnotoad (ok), 20:21, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было.

    ага, были бы проблемы куда круче.

     

  • 1.2, Аноним (-), 11:19, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >на 45% (почти в два раза!)

    А разве "2 раза" не равно 200%?

     
     
  • 2.6, EHLO (?), 11:31, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Если сократить среднее время сохранения страницы на 200%, получится машина времени.
     
     
  • 3.12, юзер (??), 12:22, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Увеличение на 45% - это почти в полтора раза. Но никак не в два.
     
     
  • 4.15, Аноним (-), 13:26, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Увеличение на 45%

    Не увеличение, а сокращение (ускорилось)

     
  • 2.16, Аноним (-), 13:33, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ЕГЭ-шные математики понабежали...
    x-45% = 0,55x
    x/(0,55x)=~1.8 - что и есть почти 2
     
  • 2.27, anonymous (??), 14:32, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Непонятно чего на человека налетели - написано ведь неправильно:
    > ...внедрение HHVM позволило в среднем на 45% (почти в два раза!) ускорить обработку...

    тоесть скорость обработки возросла на 45% (в 1.45 раза), а не время обработки сократилось на 45% (что должно соответствовать увеличению скорости обработки в 2.(2) раза или на 122.(2)%)

     
     
  • 3.28, anonymous (??), 14:42, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Прошу прощения, конечно, не 2.(2) а 1.(81) и соответственно ускорение на 81.(81)%
     

  • 1.4, Аноним (-), 11:22, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А есть сравнение сабжа с opcache
     
     
  • 2.5, Аноним (-), 11:29, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это вопрос
     
     
  • 3.13, EHLO (?), 12:30, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Это вопрос

    Это вопрос

     
     
  • 4.24, Kodir (ok), 14:06, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вопрос ли это вопроса или вопрошение спрашивающего?
     
     
  • 5.39, Какаянахренразница (ok), 18:46, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ты задаешь слишком много вопросов.
     
  • 2.62, йцу (?), 09:08, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Написано же, что с 5.6 (где опкеш по дефолту включен), разрыв не такой уж большой.
     
     
  • 3.66, funny_falcon (?), 10:43, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Уверен, дело явно не в опкеше, ибо ни кто в здравом уме и до этого без опкеша не деплоил.
    Сильно сомневаюсь, что в викимедиа наблюдается недостаток здравомыслящих людей.
     
     
  • 4.72, йцу (?), 13:07, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Значит неверно понял вопрос.
    Вообще бенчмарков за последний код была целая куча, гугл в помощь. Обычно получается что HHVM действительно в 1,5-2 раза шустрее чем PHP 5.5-5.6. Однако, с PHP7 (бывший NG) результаты уже не так однозначны - в основном они сопоставимы, местами PHP оказывается быстрее. Так что есть неслабая вероятность, что в будущем Викимедиа мигрируют обратно.
     

  • 1.8, Аноним (-), 11:57, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Вот и славно поработали, а то понимаешь "прочтите сообщение от Джимми Уэйлса"
     
  • 1.11, Аноним (-), 12:11, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    >HHVM (HipHop Virtual Machine)

    А что ты сделал для хип-хопа в свои годы?

     
     
  • 2.25, Kodir (ok), 14:07, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > А что ты сделал для хип-хопа в свои годы?

    гггг :) Я так понимаю, Богдан Титомир и был основоположником ПХП?

     
     
  • 3.103, count0krsk (ok), 21:17, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> А что ты сделал для хип-хопа в свои годы?
    > гггг :) Я так понимаю, Богдан Титомир и был основоположником ПХП?

    А разве это не Децл пел в свое время?

     

  • 1.14, Sylvia (ok), 13:05, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не дождались PHP NG, а могли бы получить тот же двухкратный прирост на "самом обычном" PHP к октябрю 2015 (релиз)
     
     
  • 2.18, Аноним (-), 13:49, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Некоторые вон реактос уже ждут 17 лет. Может быть, ну его, это ожидание? :)
     
     
  • 3.108, EuPhobos (ok), 23:51, 10/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Некоторые вон реактос уже ждут 17 лет.

    Да ладно? Зачем? Для чего?.. почему??
    Разве они не вымерли(выросли) ещё, так и ждут?

     
  • 2.19, бедный буратино (ok), 13:49, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    и как там с совместимостью? если в обычном php только и успевают раздавать deprecated (некоторые вещи в рамках 5-й ветки успели и появиться, и прожить, и стать deprecated), то слово -ng не внушает доверия. а вообще - впервые слышу про этот ng. а хип-хоп вроде бы реально работает.
     
     
  • 3.36, Sylvia (ok), 17:31, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    PHP NG тоже уже реально работает, это текущая ветка разработки
    релиз планируется к октябрю, я тестировала php-fpm sapi, вордпресс вполне работоспособен,
    работает, как и обещано, в 2 раза быстрее

    проблемы - конфигурация пулов php-fpm не прогружается полностью, ну и расширения пока готовы не все, для меня важен xcache, который к сожалению даже не в PECL'e

    Вообщем люди стараются, в первую очередь - Дмитрий Стогов

    если что - новости были, на php.net есть страничка в вики (там и про совместимость есть, не все совместимо, расширения так вообще надо серьезно перелопачивать),
    не нравится NG, ок. PHP 7.0

    А вообще хорошо что занялись наконец стандартизацией и повышением производительности, давно пора, а то популярность зашкаливает, а вот качество не дотягивает

     
     
  • 4.46, Аноним (-), 20:02, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    xcache - это стороннее расширение, которое никогда не было частью проекта php. В части опкод кэшера он больше не нужен - в ng встроенный opcache. В остальном, может быть, его автор (или кто-то еще) сделает его форк без опкод-кэшера на новом api, по аналогии с apcu.
     
     
  • 5.53, Sylvia (ok), 22:02, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    не надо мне рассказывать,
    автор не только не сделает форк без опкод кешера, но и планирует дальше его развивать,
    в частности сделать сваппинг на диск (фича была в eaccelerator)

    не все готовы принять opcache, если честно, я не знаю почему Xuefer не хочет продвинуть xcache в PECL, но бросать или как-либо менять проект он не собирается, он не из тех кто делали APC

     
     
  • 6.78, Аноним (-), 17:17, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    а что не так с opcache?
     
     
  • 7.86, Sylvia (ok), 01:57, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    нет свапа на диск -> требуется выделение большого сегмента памяти, сразу под все скрипты желательно
    удаление старых скриптов из памяти идет только через сброс всего кеша
    нет кеша переменных, соответственно придется тянуть redis,xcache,apcu

    xcache кстати как кеш переменных, даже в паре с opcache для кода, все равно рвет и memcached и прочие варианты при применении на одном сервере, за счет того что обращение идет к памяти а не по tcp, ну и в xcache есть namespaces (!)

     
     
  • 8.100, Аноним (-), 18:09, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я имею ввиду чисто как опкод-кэшер Со свопом понятно, хотя у меня даже крупн... текст свёрнут, показать
     
  • 4.74, йцу (?), 13:14, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > PHP NG тоже уже реально работает, это текущая ветка разработки
    > релиз планируется к октябрю, я тестировала php-fpm sapi, вордпресс вполне работоспособен,
    > работает, как и обещано, в 2 раза быстрее
    > проблемы - конфигурация пулов php-fpm не прогружается полностью, ну и расширения пока
    > готовы не все, для меня важен xcache, который к сожалению даже
    > не в PECL'e
    > Вообщем люди стараются, в первую очередь - Дмитрий Стогов

    Что интересно - PHP7 даёт сопоставимую (по крайней мере) производительность при том, что в нём ещё нет JIT. Интересно, что получится когда его всё-таки запилят (а над этим, если судить по рассылке активно работают).


     
     
  • 5.79, Аноним (-), 17:24, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип переменной через пару инструкций, плюс частое использование динамических вызовов по строковому имени функций и классов, от  jit в джавовском смысле толку будет мало, тут скорее нужен гибрид jit-а с рантаймом, вроде того, как в objective c в плане обмена сообщениями, ну и zval-ы оставить как есть кроме совсем простых случаев.
     
     
  • 6.94, йцу (?), 11:20, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип переменной
    > через пару инструкций, плюс частое использование динамических вызовов по строковому имени
    > функций и классов, от  jit в джавовском смысле толку будет

    В плане типов - уже сто лет как существует type hints и активно используется для аргументов, сейчас аналогично внедряют для указания типа результата. Да, пока только для объектов и массивов, но активно обсуждается и для скаляров. К тому же в том же JS, например, вообще никак нельзя указать тип, однако, это не мешает использовать JIT (сейчас, если не ошибаюсь, все актуальные JS-движки компилируют код в рантайме).

    Вызов по строке - крайне редко используется сейчас, т.к. с появляением лямбд, а так же всяких ::class становится почти не нужным.

     
  • 5.87, Sylvia (ok), 02:15, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    так уже работоспособно , берем снапшот с git ( master ) и вперед на подвиги :D
    не в production естественно
     
     
  • 6.88, Graynder (ok), 02:51, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > так уже работоспособно , берем снапшот с git ( master ) и
    > вперед на подвиги :D
    > не в production естественно

    PHP, Wordpress - Тяп ляп и в production )

     
     
  • 7.89, Sylvia (ok), 05:46, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ну у большинства так и есть
    http://blog.bnkomi.ru/content/post/13855/vovka_32787390_orig_.jpeg
     
  • 6.92, йцу (?), 11:08, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > так уже работоспособно , берем снапшот с git ( master ) и вперед на подвиги :D

    стоп, а разве JIT уже в мастере? Стогов вроде писал, что пока только работают над этим и NG - это первый шаг. Т.е. у них уже были какие-то наработки в плане just-in-time, но оказалось, что гораздо больший профит можно получить от оптимиизации аллокаций памяти + В рамках того же NG был проделан огромный рефакторинг, на основе которого и планируют добавить JIT. Разве нет? Я что-то пропустил?

     
     
  • 7.93, Sylvia (ok), 11:19, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ветку phpng уже отправили в master, да
    что там с JIT я пока не в курсе, большинство стандартных расширений (включенных в поставку) уже портировали
     
     
  • 8.95, йцу (?), 11:22, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, про это в курсе Но нет, JIT там пока нет Не факт что будет в PHP7, хотя... текст свёрнут, показать
     
  • 3.45, Аноним (-), 19:57, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Совместимость на уровне php-кода - практически 100%, за исключением пары недокументированных хаков, эксплуатирующих особенности старой реализции. Сишные расширения - да, все надо портировать.
     

  • 1.17, бедный буратино (ok), 13:48, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    хип-хоп маньяки на острие атаки!

    ps. не взлетит. в смысле, завтра ещё 400 серверов потребуется для нормальной жизни.

     
     
  • 2.20, Аноним (-), 13:50, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > ps. не взлетит.

    Уже взлетело и развернуто.


     
  • 2.43, Нанобот (ok), 19:25, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >не взлетит

    чтоб взлетело, попробуй его авиатопливом заправлять. а то на самогоне оно ясен пень не взлетит

     

  • 1.23, manster (ok), 14:02, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    этот хихивм поддерживает последние фичи пыха?
     
     
  • 2.34, vitalif (ok), 17:10, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    больше того он ещё и типизированный PHP поддерживает =)) под названием Hack...
     
  • 2.55, SubGun (ok), 02:20, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да. У меня завелся и взлетел портал без проблем. Проблемы возникли со сторонними модулями, типа predis.
     

  • 1.30, universite (ok), 15:18, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >поэтому разрыв между PHP 5.6 и HHVM был бы не столь значимым

    Вместо миграции на новую версию php, они смигрировали куда-то вбок....

     
  • 1.32, qwerty (??), 15:56, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    а где исходники?  хочу под слакварей попробывать
     
     
  • 2.37, Sylvia (ok), 17:34, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    http://hhvm.com/

    на i686 не работаеть, и не будет.

     

  • 1.35, th3m3 (ok), 17:28, 07/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    За 9 месяцев можно было переписать всё на что-то более адекватное, чем php. И никакие костыли типо хип-хопов не понадобились бы. И хип-хоп этот, тоже не панацея. Чудеса он не творит, ибо php во все поля.
     
     
  • 2.42, vitalif (ok), 19:19, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ага, давай, начинай переписывать. Ты сначала посмотри сколько там кода, а потом говори. Там же расширений ещё over 2000
     
     
  • 3.60, th3m3 (ok), 07:42, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А что поделать.
     
     
  • 4.63, йцу (?), 09:11, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А что поделать.

    Может попробовать перестать нести чушь?

     
  • 2.96, Kodir (ok), 15:28, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы разрабы вики имели мозги, они сам проект никогда не начали бы на похапэхе, так что вы слишком лестного мнения об их возможностях :) Я б тоже переписал, тем более, что уже понаписана куча веб-движков на всех мыслимых языках.
     

  • 1.57, Dzmitry (??), 04:47, 08/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > время сохранения изменений сократилось в среднем с 6 до 3 сек

    Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах. Если 500+ мс на выполнение реквеста -- это уже баг, надо фиксить, обычно меньше 100 должно быть.
    Теперь понятно почему Викимедия клянчит деньги на поддержку. Планету греет датацентрами.

     
     
  • 2.69, gaga (ok), 12:07, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Верно ли я понимаю, что у вашего приложения также не меньше 20 миллиардов просмотров в месяц и десятки тысяч хитов в секунду?
     
  • 2.82, arisu (ok), 18:35, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Эээ. Я на жаве пишу веб-приложения

    бывает, да. ну ничего, со стороны это незаметно обычно: если будешь молчать, окружающие будут считать человеком.

     
  • 2.97, Kodir (ok), 15:30, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах.

    +1! Запрос дольше 1 секунды - это уже дикость. Тем более, что у вики структура задачи проще, чем гугл.

     
  • 2.99, edwin3d (ok), 17:51, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> время сохранения изменений сократилось в среднем с 6 до 3 сек
    > Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются
    > в миллисекундах. Если 500+ мс на выполнение реквеста -- это уже
    > баг, надо фиксить, обычно меньше 100 должно быть.

    Понимаете, запросы бывают разные, совсем разные ... я займу у Вас 5 мин.
    вот бы у меня случай, когда работали над оптимизацией ... ну скажем так - приложения.
    И была там подсистема, которая отвечала за генерация аналитики.
    Выглядело это так:

    Клиент (графики на d3.js) <> J2EE приложение <> БД Oracle

    Суть в том, что каждый клиент (а их было порядка 300-400 online) должны были получать свои персональные графики. А генерация данных для этих графиков peer client занимала порядка 2c.
    Причем это было именно то время, за которое отрабатывала хранимка на БД.
    Применять пул потоков для slow запросов такого рода было нецелесообразно, т.к. это непроизводительная трата ресурсов, потому мы добавили еще один backround слой, который для online клиентов в цикле постоянно генерирует данные, а запросы от клиента просто эти данные получают.

    Так вот это все рассказал к тому, что в реальности slow запросы есть в любой серьезном приложении и их наличие не есть признак плохих разработчиков. Не факт, что их видит клиент ... но ведь операция внесения изменений не простая, согласитесь - это не тупой UPDATE одной записи, там очень серьезная логика ...

     

  • 1.58, Аноним (-), 06:02, 08/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    древний движок википедии не тормозил на 64киб,
    а щас гамно. на андроиде в фирефоксе.
     
  • 1.59, Аноним (-), 06:03, 08/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    форкать надо ето дело.
     
     
  • 2.98, Kodir (ok), 15:31, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > форкать надо ето дело.

    ДАВНО УЖЕ. Лурк - наше всё. :))

     

  • 1.64, Аноним (-), 10:27, 08/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Долго читаю здесь подобные разговоры Насколько я понял, от качества языка завис... большой текст свёрнут, показать
     
     
  • 2.65, Аноним (-), 10:42, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Дополню свое сообщение.
    От качества языка зависит, конечно же, не только скорость отладки, но и, возможно, качество сопровождения программы - чем менее популярный язык, тем сопровождение может быть хуже(а может и нет, если она написана достаточно качественно?)

    Поправлюсь: у серверов(потому что это серверы) аппаратная часть поуже - и если кто-то из своего смартфона на ARM пытается сделать web-сервер, то последнее время он "светится" на opennet, что грустно :(

     
     
  • 3.67, edwin3d (ok), 10:58, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Поправлюсь: у серверов(потому что это серверы) аппаратная часть поуже -

    Шире, причем сильно.
    И соседство PowerPC и x86 серверов вполне реальная картина  

    > и если
    > кто-то из своего смартфона на ARM пытается сделать web-сервер

    Вы не в курсе реального положения дел. ARM сервера - уже реальность.
    Начиная от ProLiant m400 до продукции "Рикор"
    И продукты набирают популярность, хотя на данный момент ориентация - нишевая.
    С силу ряда очевидных причин, не последняя из которых - эффективность энергопотребления


     
     
  • 4.70, Аноним (-), 12:10, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем случае в байт-код, а не в инструкции процессора.
     
     
  • 5.71, Аноним (-), 12:17, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем
    > случае в байт-код, а не в инструкции процессора.

    С точки зрения энергосбережения это было бы О-ГО-ГО


     
  • 5.81, Аноним (-), 17:45, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    потому что "бутылочное горлышко" у серверов уже давно не процессоры, а ПЗУ и сеть ;)
     

  • 1.102, Ящ (ok), 21:14, 09/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Жесть :) Стоило раз в позитивном ключе заикнуться про жабу...
     
  • 1.104, Аноним (-), 21:21, 09/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Давно пора ее переписать на ноде-дж-с
     
     
  • 2.107, Ящ (ok), 08:12, 10/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Шило на мыло.
     

  • 1.106, Vitold S (?), 03:38, 10/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне вот интересно, а когда уже напишут граматику MediaWiki на C и вкопилят в Си? Сколько еще ждать? Сколько еще смотреть на то как они кобяняться с PCRE и кучей каких-то костылей?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру