Как стать автором
Обновить
68
0

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

Отправить сообщение
Я долго работаю в Баду и не хожу на корпоративные посиделки, потому что предпочитаю провести время с семьёй. Меня не увольняют :)
Я думаю что этот плагин плохо подходит для работы с бинарными данными из-за наличия разделителей. То есть в качестве разделителя надо выбрать такой символ, которого не может быть в ваших данных. Тут проще и надёжнее делать base64 или что-то похожее, но это увеличит размер данных

Про производительность я в последнем разделе написал, что у нас там нет большой нагрузки и скорее всего в ближайшее время не появится. Поэтому на наших цифрах судить о производительности бессмысленно. У нас сейчас всё работает на дефолтных настройках на серверах, на которых есть и другая нагрузка, и нам пока даже нет смысла тратить время на исследования и оптимизации.
Цифры будут зависеть от многих факторов
  • есть ли другая нагрзука на сервер,
  • реплицируются ли данные,
  • включено ли кеширование (здесь про cache_policies )
  • размеры батчей (см здесь)

Если мы всё же решимся использовать этот плагин в каком-нибудь высоконагруженном месте, то скорее напишем отдельную статью с цифрами
Да, вы правы.
Похоже я тут был не совсем точен. Судя по доке ограничение на 250 символов — это ограничение именно memcached, а не memcached-протокола
Также судя по доке, innodb_memcached поддерживает бинарный протокол. Но мы пока использовали только текстовый
там есть dev.mysql.com/doc/refman/8.0/en/innodb-memcached-security.html но оно никак не привязано к mysql-юзерам. Но деталей не знаю, мы этим не пользовались
Процесс установки pinba2 не стал особо легче.

А докер эту проблему не решает?
Через год сами разработчики уже в собственном коде не могут разобраться
У нас 12-летний легаси и мы как-то справляемся :) С этой проблемой очень помогают правильно настроенные процессы. В частности у нас все коммиты привязаны к тикетам в jira. Поэтому сделав git blame и посмотрев описание коммит а, я вижу в каком тикете были сделаны данные изменения и обычно из тикета ясны почти все детали.

Что касатеся перехода на другие языки, то я в начале статьи писал, что у нас миллионы строк php-кода. Их нельзя по-быстрому переписать на руби или питон. Но у нас есть движение в сторону более активного использования Go.
Напоминаю, что я не автор psalm-а, претензии лучше высказывать напрямую автору
На такой пример psalm ругается — getpsalm.org/r/075628070d, так что я думаю, что дело как раз в обработке ошибок.
вы считаете psalm должен здесь ругаться на то что file_get_contents() может вернуть false?
В этом случае будет сгенерирован warning, многие современные фреймворки конвертируют их в Exception-ы. Анализаторы, как мне кажется, считают что эти случаи можно не анализировать.
А вы пробовали писать автору psalm-а? Все зарепорченные нами баги он довольно быстро исправил. Хотя возможно наши баги не были такими сложными.

Так что анализатор в целом может помочь, но расслабляться ни в коем случае нельзя.
Всё верно. Именно поэтому мы используем все 3 анализатора + тесты + ручное тестирование
Ну, за желания не судят :) До реальных действий дело не дошло

Но про патч я всё-таки поясню.
В типичном PHP-коде, написаном без strict_types, все эти неявные преобразования уже происходят. Такова система типов PHP, по крайней мере до времён strict_types.
PHP-программисты часто используют например var_export($some_var,1) и это работает так, как программист ожидает, хотя вторым параметром надо передавать boolean. Патч показал бы нам такие места.
Спасибо тебе за такую полезную статью! Мы ломали голову – стоит ли писать последний абзац, но не решились :)
решение для «Избегайте проверки типов (часть 1)» будет ещё лучше если интерфейсы использовать:
interface Movable { public function move(...); }
function travelToTexas(Movable $vehicle) { ... }
По-моему непонимание происходит из-за того, что вы воспринимаете кафку как очередную message queue.
В обычных message queue producer кидает событие в очередь, consumer (обычно один) получает это сообщение из очереди и выполняет свою работу и если всё ok, отвечает очереди что сообщение обработано (если это at-least-once) и это сообщение удаляется из очереди.

Кафка может быть использована как очередь сообщений, но в целом это более универсальная штука — распределённый лог событий. Producer добавляют в лог событие. Если кафка отвечает ему ok, это значит что она получила это событие и сохранила его на диск в указанный topic. Всё! Это сообщение больше не потеряется, кафка сохранила его на диск, producer может на этом успокоиться и больше не посылать это сообщение в кафку.

Далее в ход идут consumers. Одно сообщение в кафке может быть обработано несколькими разными consumer-ами.
То есть например юзер оплатил товар, система сохранила в кафку в topic ORDERS, что такой-то юзер оплатил такой-то товар, который надо доставить по такому-то адресу. Один consumer занимается тем что формирует заявку для склада, другой — добавляет это событие в финансовые отчёты, третий — сохраняет это событие в систему бизнес-аналитики. 3 разных консумера обрабатывают одно и то же событие. И после того как они обработают его, событие из кафки никуда не удаляется, оно там остаётся в течение какого-то времени (день, неделя, месяц — как настроите).

Если в одном из консумеров нашёлся баг, можно исправить баг и перезапустить консумера по всем данным которые есть в topic ORDERS — например перезалить данные в систему бизнес-аналитики.

В такой системе producer вообще не знает, обработано ли его сообщение, потому что он не знает, сколько consumer-ов его обработают и когда они должны его обработать.

Семантика exactly-once на стороне producer-а решает немного другую проблему.
В предыдущем комменте я писал:
consumer должен сам позаботиться чтобы не обработать одну и ту же запись несколько раз. Для этого можно использовать offset, который есть у каждого event-а и который монотонно растёт. То есть клиент может у себя в хранилище сохранять последний обработанный offset и по нему фильтровать дубли

эта штука работает нормально только если в самой кафке нет дублей. То есть в старых версиях могла быть ситуация, когда producer мог сохранить одно и то же сообщение в кафке дважды. В этом случае у этих 2-х сообщений будут разные offset-ы и эта схема дедупликации не сработает (можно делать дедупликацию вручную, зная какие данные у тебя в событии, но тогда для каждого события должен быть свой код для дедупликации)
не уверен что понял вопрос точно
В кафке есть 2 типа «клиентов» — producer (кто сохраняет события в кафку) и consumer (потребляет события)
Механизм exactly-once — он только для producer-ов, то есть если producer по какой-то причине не уверен, сохранилось ли сообщение в кафку (например разрыв соединения), он просто перепошлёт сообщение в кафку с тем же ID и механизм exactly-once гарантирует, что event не будет продублирован

Полагаю что вопрос всё же был про consumer-ов.
Здесь кафка не даёт гарантий exactly-once и consumer должен сам позаботиться чтобы не обработать одну и ту же запись несколько раз. Для этого можно использовать offset, который есть у каждого event-а и который монотонно растёт. То есть клиент может у себя в хранилище сохранять последний обработанный offset и по нему фильтровать дубли
Сильно зависит от реализации на стороне сервера.

Насколько я понимаю, идеальный вариант — самый первый запрос в HTTP/2 соединении должен вернуть ответ + пушнуть эту таблицу стилей с правильными заголовками, чтобы стили попали в HTTP-кеш. Все последующие запросы внутри этого HTTP/2-соединения не должны пушить эту таблицу стилей, браузер и так из http-кеша возьмёт её. Если соединение разорвалось, то в новом HTTP/2-соединении на первый запрос можно отвечать даже без пуша стилей — они ведь и так есть в кеше. Но определить всё это на стороне сервера — довольно муторное занятие.

Я пока соглашусь с самым первым комментарием: «Слишком мало профита для столь сложной технологии.»
удалено, промахнулся с ответом
про все кеши я не смогу рассказать, но про кеш сервис-воркеров наверное можно почитать статью того же автора — https://jakearchibald.com/2014/offline-cookbook/ или курс на udacity https://www.udacity.com/course/offline-web-applications--ud899
насчёт preload кеша речь, насколько я понимаю, идёт о https://w3c.github.io/preload/
Там в разделе Processing (https://w3c.github.io/preload/#processing) в заметках в конце есть пример, объясняющий почему для preload-а может понадобиться отдельный кеш, а не http-cache
да, спасибо поправил
спасибо исправил

Информация

В рейтинге
Не участвует
Откуда
Richmond, England - London, Великобритания
Дата рождения
Зарегистрирован
Активность