Пост «Теория ограничений в PHP» является редакционной статьей для бюллетеня канала PHP от 11 июля. Чтобы быть в курсе новостей, сообщений и соответствующих ссылок PHP, зарегистрируйтесь здесь .
Я читал The Phoenix Project , замечательный роман об ИТ (вы правильно прочитали), который представляет повседневные информационные технологии и разбирает проблемы в большой компании, похожей на Amazon, таким образом, что смертные понимают сложности и хаос 21-го века. технологии.
Не раздавая никаких спойлеров, в одном месте книги упоминается Теория ограничений. Согласно Википедии:
Теория ограничений (TOC) — это парадигма управления, которая рассматривает любую управляемую систему как ограниченную в достижении большего количества своих целей из-за очень небольшого числа ограничений. Всегда есть хотя бы одно ограничение, и TOC использует процесс фокусировки, чтобы определить ограничение и реструктурировать остальную часть организации вокруг него.
Теория ограничений может быть сведена к идее, что цепь настолько сильна, насколько ее самое слабое звено .
В книге это было сформулировано так:
Любые улучшения, сделанные где угодно, кроме узкого места, являются иллюзией.
По какой-то причине это вызвало у меня гораздо больший резонанс, чем цепная идиома. Просто есть что-то в создании чего-то, что неэффективно, что для меня более важно, чем ломать что-то, что слабо построено .
Фабрики и Браузеры
Как (первоначально) было представлено в книге и слегка ошарашено, фабричный цех видел кучу рабочих заданий за одним столом, а остальные участки фабрики работали несколько удовлетворительно. Не работая над оптимизацией пропускной способности этого одного стола и (путем совпадения или преднамеренного) обновления процесса, который предшествует или заменяет его, фабрика забилась работой, потому что первые приводят к стеку продуктов перед столом, который не имеет места назначения, и последние приводят к тому, что на другом конце предприятия не работают работники, которые ждут, пока продукты доставят их для отправки, но все застряли в медленной обработке на центральном столе.
Чтобы немного коснуться здесь — если вы следите за мной в Твиттере, вы знаете, что я люблю разглагольствовать о браузерах . Я особенно теряю его, когда они помещают обновления, такие как нативные уведомления OSX, но не решают проблему использования оперативной памяти, существовавшую десятилетиями. Некоторые люди быстро относятся к этому как к обращению к ошибочности худших проблем , но я не согласен. Хотя да, это обращение к более серьезной проблеме, но я не вижу в этом заблуждения — скорее, я вижу в нем отсутствие определенных ограничений со стороны Google. Как компания, они кажутся совершенно невежественными в отношении того, что нуждается в оптимизации, или лишены ресурсов, предназначенных для решения этой проблемы (не уверен, что хуже). Таким образом, все эти «улучшения» сделаны вне узкого места, сводя с ума опытных пользователей и приводя к попыткам обновить браузер, добавив к нему другой скин (Вивальди, Храбрый, Опера, Призрак…), но не в состоянии добиться прогресса, потому что, опять же, узкое место остается. Если вы переместите стол и всю заводскую настройку из одного здания в другое, стол все равно будет проблемой. Починить стол.
Теория ограничений в PHP
Итак, как это относится к веб-приложениям? Или, что еще лучше, PHP-приложения в частности?
В наши дни очень легко следовать этому принципу и определить ограничения. В нашем распоряжении так много удивительных инструментов, что определение узкого места в течение нескольких часов, как правило, само собой разумеющееся:
-
Blackfire предоставит вам фантастические подробные графики стека выполнения вашего приложения, с легкостью указывая на узкие места кода. Они также будут включать узкие места в базе данных, если они выполняются в анализируемом стеке кода, что значительно упрощает оптимизацию всего этого.
-
Не многие знают это, но Xdebug имеет ту же диаграмму стека выполнения с анализом времени , что позволяет вам делать то же самое локально!
-
Существует множество ценных инструментов обеспечения качества, которые могут помочь вам протестировать ваше приложение на куски — очень длительное время тестирования часто свидетельствует о наличии узких мест, и их точное определение там, пока они работают с фиктивными данными, и примеры тестирования могут быть невероятно полезными.
-
Немного старомодный , но золотой , этот набор постов поможет вам оптимизировать ваш MySQL после того, как вы определили его как узкое место …
Но помните, что оптимизировать его ради оптимизации — не очень хорошая идея!
-
Это поможет, если вы обработаете ваше приложение запросами и сравните результаты до / после — это будет четким показателем того, насколько оптимизация значительно повысила приложение в целом. В этом может помочь такой инструмент, как Siege, и у нас есть подробное руководство по этому вопросу.
Приведенные выше инструменты — хорошее начало, но далеко не исчерпывающее и далеко не применимое к любой проблеме, с которой вы можете столкнуться. Дополнительные статьи из этой Premium PHP Anthology о лучшей разработке PHP могут быть полезны, но я искренне надеюсь на более разнообразные примеры и ссылки от вас! Стреляй!
Вывод
ToC является серьезной проблемой в разработке программного обеспечения, и так же, как и везде. Мы все сталкивались с узкими местами, и все мы тупо пытались улучшить что-либо кроме узкого места — или, если вы еще не попали в эту ловушку, я обещаю, что вы это сделаете.
К счастью, в экосистеме PHP появились инструменты, которые помогают выявлять узкие места и превращать их в системные ограничения. Если ваше приложение имеет проблемы с производительностью или пропускной способностью, найдите узкое место, отметьте его, а затем отбросьте всю остальную работу, пока узкое место не будет устранено. Освободите критичных людей от других задач, даже если это означает игнорирование входящих не связанных высокоприоритетных задач, и попросите всех, кто квалифицирован, сосредоточиться на этой одной проблеме, пока она не будет решена. Вся система будет благодарна вам за это, потому что, чаще всего, это узкое место является причиной этих других первоочередных билетов в первую очередь. Не загоняй себя в угол! (Чтобы понять эту ссылку, вам нужно прочитать книгу)
Если вы летите в одиночку, применяются те же принципы — когда вы смотрите на свои столбцы задач в Trello, Zenkit, Freedcamp или другом инструменте управления проектами, найдите одно узкое место, закрасьте его красным и переместите все остальные в столбец вне экрана или столбец, который можно свернуть до тех пор, пока ограничение не будет устранено и система не будет перестроена вокруг него. Если вы сделаете что-то меньшее, вы получите массу технических долгов, которые потом похоронят вас.
Как вы находите свои узкие места? Вы переделываете систему вокруг идентифицированного ограничения, или вместо этого вы переделываете ограничение и пытаетесь взломать его? Какие инструменты / учебники я пропустил в приведенном выше списке? Дайте мне знать в комментариях — давайте вместе составим полный список — и помните: «Улучшение ежедневной работы даже важнее, чем ежедневная работа »! (Еще одна замечательная цитата из книги)