Ой, а Вы не в курсе? Она же давно уже есть! Конфуций, Макиавелли, Форд и много других умных людей уже давно изложили массу умных мыслей о менеджменте (только они это называли другим словом). Создавать теорию всего совсем не надо — она есть и давно и налаженно работает в руководящих аппаратах государств.
Просто Вы не ссылаетесь на зарекомендовавшие себя практики
Простите… Вы помоему меня не поняли. Я ссылаюсь на общепринятую практику появившуюся за 1000 лет до появления IT, зарекомендовавшую себя за эту 1040 лет. Я провожу параллель между практиками военного и оханного дела и современным IT (который по какой то случайности эти практики пытается придумать заново). Вы говорите модными сокращениями в 2-4 буквы вроде «PM» и «ITSM», а я говорю понятным всем языком — вот разница между нашими взглядами.
Я не в курсе того, что у Вас есть, в том числе и что для Вас банальность
Странный у нас диалог… Вы ничего обо мне не знаете, при этом учите. Правда странно. Хотя может быть и я Вас не понял.
Да это просто пример который есть сходу. Вообще, по уму — VPN/vlan с площадки в другое место, все гонять по серым адресам VPN-а, а наружу ходить из другого места. Большинство проблем с палевом решит.
Начал с ковыряния в расширениях php, потом решил сделать собственный SAPI для php. Собственно горел идеей сделать php без сброса окружения, и как оказалось сделать это крайне сложно, ибо придется переделывать архитектуру самово интерпитатора. Забил на это занятие.
А информация, да, из сырцов. Там все довольно просто, кроме того, что все раскидано по файлам хаотично.
Напимер те же extension имеют вхождения .MINIT и .MSHUTDOWN (в названиях могу путаться), но суть сохраняется. MINIT вызывается при инициализации, MSHUTDOWN при выгрузке модуля. Обычно в MINIT делают всякие malloc и обнудения переменных, в MSHUTDOWN free. Ну это так, по простому. Инициализация с сброс окружения вызывают соответственно MINIT и MSHUTDOWN каждого расширения. Ну если окружение не сбросить — память потечет во всех расширениях, если не сделать инициализацию — будут segfault-ы. Вот он и порочный круг php — инициализация, выполнения, сброс. Это зашито в архитектуре.
Аналогично и с php.ini и с прочим.
Собственно по поводу сохранения состояния между запросами. Так реализован сам интерпретатор что не может. Запуская код (для php по сути «скрипт») — он инициализирует окружение (собственно его начальное состояние с загруженными extensions, конфигурацией из php.ini, а так же со всеми переменными $_SERVER, $_REQUEST и прочим) и потом начинает выполнение самого кода. Так вот, если выполнить инициализацию окружения повторно (даже не убивая сам процесс) — почистится все наглухо (так и работает fpm — обработал запрос, почистил, обработал запрос, ...). Если же этого не сделать, а просто запустить другой (или этот же) — отвалится часть окружения, конфигурация из php.ini, extensions, в том числе и необходимые переменные для работы «скрипта» (тот же $_REQUEST).
Тут дело не в языке, дело в реализации интерпретатора
Дополню: обычно «средние разработчики» пишут структурированный и слабо связанный код. Иногда модульный. А его можно разнести на сервисы. Ситуацию когда «плохие разработчики» называются средними тут рассматривать нет смысла, ибо там всегда будут пробемы с ресурсами (4 LEFT JOIN например, или MAP с foreach вместо BTREE и b-поиска и т.д.)
Я бы озвучил дополнительные проблемы:
1. Не всегда «средние разработчики» могут написать хорошо масштабируемое решение. т.е. докупить серверов — может сделать хуже.
2. Не всегда «средние разработчики» могут хорошо оптимизировать код. обычно узкое место просто «переносится», например вместо RAM начинаю жрать CPU и Storage IO
3. Не все железо можно «проапгрейдить». Если в Вашей машине 96 GB RAM и больше не воткнуть — её не воткнуть. Ну а потом к пункту 1.
Я бы решал проблему с разных сторон:
1. Разделять систему на сервисы, чтобы конкретный «узкий» сервис масштабировать.
2. Конечно докупать железо — если у нас 100% ресурса испльзовано, завтра все равно потребуется 110% от текущего. Бизнес растет. Оптимизировать быстрее, чем масштабировать всеравно не возможно.
3. «Средних разработчиков» учить. Учить писать быстрый код, учить писать масштабируемый код.
P.S. Монитроить систему, и задаватся этим вопросом не на 100% RAM использовано — «решайте срочно и сейчас», а на 80% — «решите в течение недели».
Ой, а Вы не в курсе? Она же давно уже есть! Конфуций, Макиавелли, Форд и много других умных людей уже давно изложили массу умных мыслей о менеджменте (только они это называли другим словом). Создавать теорию всего совсем не надо — она есть и давно и налаженно работает в руководящих аппаратах государств.
Простите… Вы помоему меня не поняли. Я ссылаюсь на общепринятую практику появившуюся за 1000 лет до появления IT, зарекомендовавшую себя за эту 1040 лет. Я провожу параллель между практиками военного и оханного дела и современным IT (который по какой то случайности эти практики пытается придумать заново). Вы говорите модными сокращениями в 2-4 буквы вроде «PM» и «ITSM», а я говорю понятным всем языком — вот разница между нашими взглядами.
Странный у нас диалог… Вы ничего обо мне не знаете, при этом учите. Правда странно. Хотя может быть и я Вас не понял.
Я как то решил не писать такой банальный момент, вроде как и так понятно
Вы так пишите, как будто у нас ничего нет, ни мониторинга, ничего. Ну зачем Вы так? Вокруг умные здоровые умом люди.
Ну если адреса свои, то да. А если арендована стка /25 у хостера, то нет. Если у компании свои IP и AS — столько перспектив сразу открывается для DDoS
А информация, да, из сырцов. Там все довольно просто, кроме того, что все раскидано по файлам хаотично.
Аналогично и с php.ini и с прочим.
Тут дело не в языке, дело в реализации интерпретатора
Я бы озвучил дополнительные проблемы:
1. Не всегда «средние разработчики» могут написать хорошо масштабируемое решение. т.е. докупить серверов — может сделать хуже.
2. Не всегда «средние разработчики» могут хорошо оптимизировать код. обычно узкое место просто «переносится», например вместо RAM начинаю жрать CPU и Storage IO
3. Не все железо можно «проапгрейдить». Если в Вашей машине 96 GB RAM и больше не воткнуть — её не воткнуть. Ну а потом к пункту 1.
Я бы решал проблему с разных сторон:
1. Разделять систему на сервисы, чтобы конкретный «узкий» сервис масштабировать.
2. Конечно докупать железо — если у нас 100% ресурса испльзовано, завтра все равно потребуется 110% от текущего. Бизнес растет. Оптимизировать быстрее, чем масштабировать всеравно не возможно.
3. «Средних разработчиков» учить. Учить писать быстрый код, учить писать масштабируемый код.
P.S. Монитроить систему, и задаватся этим вопросом не на 100% RAM использовано — «решайте срочно и сейчас», а на 80% — «решите в течение недели».