Обновить
23
0
Роман «Balancer» Каршиев@Bal

Пользователь

Отправить сообщение
Мой проект прошлой осенью активно какие-то недоброжелатели запихивали в Спамхаус. Соответственно, отваливались службы, которые его параметры использовали для режекта — в первую очередь hotmail.com и rambler.ru. Пришлось так и писать пользователям — используйте вменяемые почтовые сервисы, с параноиками мы бессильны :) Потом, пару месяцев спустя недоброжелатели, правда, устали и предупреждение было убрано. Но народ относился с пониманием и спокойно регистрировался с Гугла или Яндекса.
Ужас начинается, когда появляется что-то типа:
<a href="<?= $page->url ?>">...</a>
От такого обилия вложенных угловых скобок глаза начинает колбасить.

Плюс чистый PHP не позволяет удобно использовать всякие полезные вещи, типа наследования шаблонов, автоматического экранирования и т.п.
Странно. Одно время (но не долго) использовал Composer именно на VPS с 512Мб (DigitalOcean). Но потом до 1Гб расширил, MySQL базы не маленькие нужны.

И лимит памяти для PHP в cli на машинах стоит часто 128 или 256Мб — хватает.
Жали только, что bower за собой всю NodeJS тянет. Приходится на паре машин держать этого монстра только для того, чтобы пакеты под PHP ставить :) Composer в этом смысле несравнимо изящнее, потому что автономный.
0.1% — это один из тысячи. Даже если в окружении человека в 10 раз больше умных, чем в среднем, десяток знакомых указывает на 1000 людей в окружении достаточно близких, чтобы оценить уровень их интеллекта. При чём тут много допущений — и умных людей в окружении IT-шников обычно не в 10 раз больше среднего уровня, и для IQ 160 всё будет ещё хуже (намного), чем для IQ 150. У меня в близком окружении многие десятки умных людей. Но по пальцам можно пересчитать тех, IQ которых более 135.
>RAID+бэкап никто не отменял…

RAID — защита от выхода из строя, не но защита от ошибок чтения. И забекапить можно уже повреждённый при чтении файл.
Проверял на 2.2.0 и 2.4.2. Первый на работе с объектами/памятью/методами, действительно, был немного быстрее второго, но всё равно проигрывал PHP 5.5.3 (и был на уровне PHP 5.4.9). На конкатенации тестировал только hhvm 2.4.2 vs php 5.5

Про JIT — не в курсе. Я использовал готовые бинарники из Ubuntu PPA и просто запускал «hhvm test.php»
Я работал с компилятором Си, где NULL имел конкретный адрес, указывающий на перехватчик исключения. Так обрабатывались NPE.
Однако в первых компиляторах Си, с которыми я работал, true было равно -1. Ибо ассемблерное not 0 давало 0xFF/0xFFFF
Я делал замеры скорости HHVM vs PHP 5.4 с кешем.

HHVM на 30..50% медленнее на объектной работе и выделениях памяти. Но примерно вдвое быстрее на конкатенации строк. В среднем получается шило на мыло и что выгоднее зависит от конкретной задача и реализации, похоже.
>а как быть в случае удаления коммента?

Пересчёт номеров страниц одноразовая операция и выполняется относительно быстро. Удаление — событие нечастое, можно подождать и с пересчётом.

У меня на форуме бывает под 15 тыс. ответов в теме. До 600 страниц на топик. И это при том, что я стараюсь жёстко разделять тему на новые темы в случае её роста, так бы и многие тысячи страниц были у некоторых (а ля iXBT-style, когда найти что-то потом нереально). При реальном использовании основная масса народа постоянно пасётся именно на последних страницах, т.е. львиная масса запросов именно в духе… LIMIT 10000, 25. Когда сидит хотя бы человек 200 в онлайне, нагрузка получается очень большая. Особенно, учитывая то, что сортировка не по одному ID, а по дате сообщения, приоритету сортировки, с учётом пометки «удалено» (физическое удаление в моём случае не практикуется) и ещё что-то. Индексы получаются сложные и большие. Пришлось вводит административные ограничения «200 страниц темы — создавайте новую тему» и т.п. Параметр «страницы темы» не вводил, так как тоже опасался проблемы пересчёта. Потом составил не особенно сложный запрос пересчёта номеров страниц и ввёл соответствующую сущность. Выборки стали выполняться мгновенно.
Я ни где не писал про дистиллированную воду. Водопроводная вода, действительно, грязная и ток немного проводит. Но совершенно недостаточно для эффективного электролиза в бытовых условиях.

Опустите провода от батарейки в стакан воды и убедитесь. Потом подсыпьте соли и наблюдайте совершенно иной эффект.
Меня удивляет. Когда переписывал свой фреймворк с древнего процедурного стиля на ООП, то получал местами очень приличное ускорение. ООП позволяет программировать быстрее, абстрагироваться от деталей и поэтому реализовывать более сложные, но эффективные в плане производительности механизмы.

Когда 9-летнему Гауссу предложили посчитать сумму всех чисел от 1 до 100, он не стал как другие очень быстро-быстро складывать всё подряд, он подумал и вывел более сложную формулу, по которой и получил результат в десятки раз быстрее одноклассников :)
Электролиз обычной воды крайне медленный процесс из-за её малой электропроводности. А поваренная соль — самый доступный домашний электролит :)
Водород взрывоопасен, не пытайтесь повторить...


И при этом самый примитивный метод получения, доступный любому. Хотя бы с классическим цинком и соляной кислотой в аппарате Киппа показали бы. А так теперь кто-то затеет повторить, захочет посмотреть, как горит водород, выделяющийся из трубочки и получит взрыв гремучего газа в трёхлитровой стеклянной банке. С нехилой вероятностью летального исхода. Оно вам надо?

Всем, желающим повторить: при указанной реакции выделение водорода происходит достаточно медленно и полное вытеснение воздуха из банки будет длиться очень, очень долго. Не пытайтесь поджечь прямо выделяющийся водород в банке. С высокой вероятностью получите мощный взрыв гремучей смеси. Если сильно припрёт поджечь, то обязательно проводите пробу на гремучий газ, предварительно заполнив выделяющимся газом пробирку под водой.
Хотелось бы сравнения с Docker. Я пока не вижу, чем предложенный вариант лучше решения на Docker.
Судя по последним тенденциям этот лозунг нужно применять к GDrive ;)
Да, он. Я потому и спрашивал. У меня человека три знакомых (форумных) с Кронос'ом работали, часто тема поднималась, потому и спросил. Тесен мир :)

Жаль только, что Володя больше не с нами, земля ему пухом :( Так и не успели с ним в реальности пивка попить…
>И да, такой приём не очень явный и читабельность не сильно улучшает.

Объединение нескольких JS/CSS в один файл и их минификация читабельность тоже не повышают :) Однако являются очень рекомендуемой процедурой.
Ещё есть такой баян :)


Погрузка 305 RAMAC на самолёт :)

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность