Сейчас подсчитал - выигрыш будет шаге на 4-м уже. Контекст меньше -- соответственно каждый следующий шаг стоит дешевле и где-то с 5-го шага экономия уже превысит стоимость складывания в кэш.
Есть ньюанс - после компакции агент может забыть важное и начать читать по новой то, что уже читал до сброса. А это снова контекст раздувает.
Поэтому чем перебирать - я проанализировал логи (не сам, конечно)) на предмет какие команды вызываются часто+последовательно и микро-автоматизации для себя и команды написал. Проще и быстрее чем брать microsoft/монстра и пытаться под себя настроить.
Надо попробовать. Но я пошел другим путем - на длинных задачах у меня диспетчер который вызывает уже разраба, затем ревьювера. В итоге у каждого контекст мал (хоть и шагов много). И после ревью тотже разраб начинает заново по найденным недочетам. В итоге суммарно контекста сильно меньше. + автоматизации повер, которые рутину (подряд вызываемые операции типа определение контекста проекта, подготовка ветки и тд - делаются через вызов js метода, чтобы зазря шаги не жечь).
Так сам вызов плагина останется в истории, вместе с саммари. Контекст не сожмется. Только прямой /compact сожмет (ну или харнес автомат включит тогда контекста 200k+)
Советую присмотреться к MirrorFolder, несколько лет пользуюсь — без нареканий. Рез.копии создаются хоть куда, все настраивается под конкретную задачу. Есть возможность хранить удаленные, работать как софт-RAID и т.д.
Никогда проблем с памятью не было.
Сейчас проверил процесс, отвечающий за 2 000 ботов — крутится уже с месяц после последнего перезапуска. Памяти полпроцента. Никакой тенденции к разрастанию.
Все завязано на цикл. Все объекты создаются внутри метода, и, мне кажется, garbage collector ПХП 5.2.9 должен прекрасно с этим справляться.
При возникновении ошибок на демоне нужно архитектуру строить так, чтобы ошибки не вызывали фатального падения всей системы и подключенных пользователей.
Упал демон -> поднялся -> продолжил работать с того места на котором остановился.
А PHP это или нет, не так уж и важно. У меня в одной он-лайн игре PHP демоны работают без странностей и неприятностей.
Сейчас подсчитал - выигрыш будет шаге на 4-м уже. Контекст меньше -- соответственно каждый следующий шаг стоит дешевле и где-то с 5-го шага экономия уже превысит стоимость складывания в кэш.
Есть ньюанс - после компакции агент может забыть важное и начать читать по новой то, что уже читал до сброса. А это снова контекст раздувает.
Поэтому чем перебирать - я проанализировал логи (не сам, конечно)) на предмет какие команды вызываются часто+последовательно и микро-автоматизации для себя и команды написал. Проще и быстрее чем брать microsoft/монстра и пытаться под себя настроить.
Надо попробовать. Но я пошел другим путем - на длинных задачах у меня диспетчер который вызывает уже разраба, затем ревьювера. В итоге у каждого контекст мал (хоть и шагов много). И после ревью тотже разраб начинает заново по найденным недочетам. В итоге суммарно контекста сильно меньше. + автоматизации повер, которые рутину (подряд вызываемые операции типа определение контекста проекта, подготовка ветки и тд - делаются через вызов js метода, чтобы зазря шаги не жечь).
факт, даже больше 300к уже тупит нещадно.
я еще делаю /handoff сначала, а потом /compact - тогда детали не теряются (почти))
Так сам вызов плагина останется в истории, вместе с саммари. Контекст не сожмется. Только прямой /compact сожмет (ну или харнес автомат включит тогда контекста 200k+)
единственная видимая проблема может быть в быстродействии когда объемы возрастут, но это уже флейм))
Сейчас проверил процесс, отвечающий за 2 000 ботов — крутится уже с месяц после последнего перезапуска. Памяти полпроцента. Никакой тенденции к разрастанию.
Все завязано на цикл. Все объекты создаются внутри метода, и, мне кажется, garbage collector ПХП 5.2.9 должен прекрасно с этим справляться.
Упал демон -> поднялся -> продолжил работать с того места на котором остановился.
А PHP это или нет, не так уж и важно. У меня в одной он-лайн игре PHP демоны работают без странностей и неприятностей.