При стратегии выкладывания карт задержками всё ещё остаётся вопрос выкладывания первой карты. Получается что нужно договориться о точке синхронизации без передачи информации. А это уже задача о двух генералах которая решения не имеет.
с одной стороны вы вроде говорите, что состояние получается изолированным для каждого отдельного запроса и иного подхода потребуют, вроде как, только вполне конкретные места, типа взаимодействие с БД
Где? Вроде не говорил такого.
Типичное 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 серверов с простаивающим местом (на разных серверах разный объём). Хотелось бы собрать их в максимально простую объектную бд.
Амазон дороговат в цене за терабайт.
На мой взгляд тут нужно менять интерфейс. Поделив функцию на две: извлечение директории и извлечение файла.
Что касается отрефакторенного класса — лично меня напрягают классы которые что-то делают а потом сохраняют результат в себя чтобы вы могли достать его из свойства. На мой взгляд если вы хотите вернуть два и более значения — делите их обработку на разные публичные методы либо возвращайте структуру.
В теории возможны ошибки валидации при передачи таких id во внешние системы, но я с таким не встречался.
Postgres например эти биты не проверяет.
Умрешь!
Где? Вроде не говорил такого.
Типичное PHP приложение-сайт будет легче переписать с нуля чем натянуть на эту технологию. Проблем стоит ожидать везде где речь идёт о глобальном состоянии (синглтоны, статические свойства классов и тд) — а современный php код (как ваш так и сторонних библиотек) пишется без оглядки на это состояние.
Также следует ожидать утечечек памяти, но я так понимаю этот вопрос фиксится просто переодическим перезапуском воркеров.
Если ваше приложение использует request — response абстракции (например построено на основе symfony) и написано в академично-интерпрайз манере то ваши шансы на переход конечно возрастают, однако с ходу всё равно не заведется — нужны будут правки.
Может тогда уж просто вернёмся к умиранию?)
Нужно не забывать закрывать коннекты после обработки запроса, либо если используете пул коннектов то учитывать состояние. Чтобы не получилось так что в при обработке запроса вы открыли транзакцию и зафейлили запрос после чего бд с открытой транзакцией ушла обратно в пул.
В целом годная штука, но облать применения довольно узка так как оно не ложится на мышление современных php программистов и на сторонние библиотеки этими программистами написанные.
А также, как я писал выше, разделение одной таблицы на несколько.
Таким способом можно добавить или удалить индекс, добавить колонку с default, расширить тип данных (например с int на bigint) и тд.
К сожалению наши изменения под этот формат не подходили.
На остальных бд у нас 5.7
InnoDB — наш основной движок. Ещё были эксперименты с MyRocks, но он не взлетел.
Амазон дороговат в цене за терабайт.
Иногда лучше иметь 10 программистов и возможность подключить ещё 20 если будет нужно, чем одного и проект который кроме него никто никогда не поймёт.
Что касается отрефакторенного класса — лично меня напрягают классы которые что-то делают а потом сохраняют результат в себя чтобы вы могли достать его из свойства. На мой взгляд если вы хотите вернуть два и более значения — делите их обработку на разные публичные методы либо возвращайте структуру.