При стратегии выкладывания карт задержками всё ещё остаётся вопрос выкладывания первой карты. Получается что нужно договориться о точке синхронизации без передачи информации. А это уже задача о двух генералах которая решения не имеет.
с одной стороны вы вроде говорите, что состояние получается изолированным для каждого отдельного запроса и иного подхода потребуют, вроде как, только вполне конкретные места, типа взаимодействие с БД
Где? Вроде не говорил такого.
Типичное PHP приложение-сайт будет легче переписать с нуля чем натянуть на эту технологию. Проблем стоит ожидать везде где речь идёт о глобальном состоянии (синглтоны, статические свойства классов и тд) — а современный php код (как ваш так и сторонних библиотек) пишется без оглядки на это состояние.
Также следует ожидать утечечек памяти, но я так понимаю этот вопрос фиксится просто переодическим перезапуском воркеров.
Если ваше приложение использует request — response абстракции (например построено на основе symfony) и написано в академично-интерпрайз манере то ваши шансы на переход конечно возрастают, однако с ходу всё равно не заведется — нужны будут правки.
>В теории, если внести создание $app и $kernel внутрь цикла, то сборщик мусора при каждом новом запросе будет чистить абсолютно все.
Может тогда уж просто вернёмся к умиранию?)
Ведут себя нормально, так как со сторны php это не форки а просто выполнение разных запросов в цикле.
Нужно не забывать закрывать коннекты после обработки запроса, либо если используете пул коннектов то учитывать состояние. Чтобы не получилось так что в при обработке запроса вы открыли транзакцию и зафейлили запрос после чего бд с открытой транзакцией ушла обратно в пул.
В целом годная штука, но облать применения довольно узка так как оно не ложится на мышление современных php программистов и на сторонние библиотеки этими программистами написанные.
Да. У нас много мелких запросов вида «Дай юзера по id». Недавний нагрузочный тест показал что если делать эти запросы на чистом sql то CPU load сервера возрастает до 70% — 85% против 30% — 35% с HS
Да. У нас было изменение типа данных колонки с varchar на binary с меньшей размерностью (данные тоже сжимались).
А также, как я писал выше, разделение одной таблицы на несколько.
Это отличный способ, но чтобы им воспользоваться изменения должны быть обратно совместимы с запросами в мастер (insert, update, delete должны корректно проходить на изменённом слейве).
Таким способом можно добавить или удалить индекс, добавить колонку с default, расширить тип данных (например с int на bigint) и тд.
К сожалению наши изменения под этот формат не подходили.
UDB работает на 5.5 так как мы активно используем HandlerSocket который не поддерживаться в следующих версиях. Сейчас тестируем 8.0 c memcached и x protocol как замену HandlerSocket.
На остальных бд у нас 5.7
Foreign Keys используются редко, только в не highload частях. В UDB их конечно нету.
InnoDB — наш основной движок. Ещё были эксперименты с MyRocks, но он не взлетел.
Ключ по которому мы разбивали таблицу уже был во всех уникальных индексах, включая PK. Поэтому уникальность никак не пострадала, и так-же поддерживается средствами MySQL.
А можете посоветовать подобное объектное хранилище но попроще? Есть около 5 серверов с простаивающим местом (на разных серверах разный объём). Хотелось бы собрать их в максимально простую объектную бд.
Амазон дороговат в цене за терабайт.
На мой взгляд тут нужно менять интерфейс. Поделив функцию на две: извлечение директории и извлечение файла.
Что касается отрефакторенного класса — лично меня напрягают классы которые что-то делают а потом сохраняют результат в себя чтобы вы могли достать его из свойства. На мой взгляд если вы хотите вернуть два и более значения — делите их обработку на разные публичные методы либо возвращайте структуру.
Как генерируются UUID
В теории возможны ошибки валидации при передачи таких id во внешние системы, но я с таким не встречался.
Postgres например эти биты не проверяет.
Как генерируются UUID
Умрешь!
Стратегия игры в телепатию
RoadRunner: PHP не создан, чтобы умирать, или Golang спешит на помощь
Где? Вроде не говорил такого.
Типичное PHP приложение-сайт будет легче переписать с нуля чем натянуть на эту технологию. Проблем стоит ожидать везде где речь идёт о глобальном состоянии (синглтоны, статические свойства классов и тд) — а современный php код (как ваш так и сторонних библиотек) пишется без оглядки на это состояние.
Также следует ожидать утечечек памяти, но я так понимаю этот вопрос фиксится просто переодическим перезапуском воркеров.
Если ваше приложение использует request — response абстракции (например построено на основе symfony) и написано в академично-интерпрайз манере то ваши шансы на переход конечно возрастают, однако с ходу всё равно не заведется — нужны будут правки.
RoadRunner: PHP не создан, чтобы умирать, или Golang спешит на помощь
Может тогда уж просто вернёмся к умиранию?)
RoadRunner: PHP не создан, чтобы умирать, или Golang спешит на помощь
Нужно не забывать закрывать коннекты после обработки запроса, либо если используете пул коннектов то учитывать состояние. Чтобы не получилось так что в при обработке запроса вы открыли транзакцию и зафейлили запрос после чего бд с открытой транзакцией ушла обратно в пул.
В целом годная штука, но облать применения довольно узка так как оно не ложится на мышление современных php программистов и на сторонние библиотеки этими программистами написанные.
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
А также, как я писал выше, разделение одной таблицы на несколько.
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
Таким способом можно добавить или удалить индекс, добавить колонку с default, расширить тип данных (например с int на bigint) и тд.
К сожалению наши изменения под этот формат не подходили.
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
На остальных бд у нас 5.7
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
InnoDB — наш основной движок. Ещё были эксперименты с MyRocks, но он не взлетел.
Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo
Объектное хранилище NetApp StorageGrid
Амазон дороговат в цене за терабайт.
Deployer — удобный и гибкий деплой приложений
Работа с MySQL: как масштабировать хранилище данных в 20 раз за три недели
himawari8 wallpaper для linux
Борьба с «плохими» URI, спамерами и php-шеллами — личный опыт
Пишем maintainable код
Иногда лучше иметь 10 программистов и возможность подключить ещё 20 если будет нужно, чем одного и проект который кроме него никто никогда не поймёт.
Рефакторинг: выделяй метод, когда это имеет смысл
Что касается отрефакторенного класса — лично меня напрягают классы которые что-то делают а потом сохраняют результат в себя чтобы вы могли достать его из свойства. На мой взгляд если вы хотите вернуть два и более значения — делите их обработку на разные публичные методы либо возвращайте структуру.