Страшные сказки про PHP5, рассказанные на ночь…

    1) Какой бы ерундой вы не занимались с PHP, узкое место _всегда_ — БД. PHP — он как Буратино — тупОЙКАк… дрова. Lighttpd и Nginx позволяют разнести его по множеству физических серверов на раз без шума и пыли. Зарплата адекватного спеца по PHP в Москве — 30-45 тыс. рублей в месяц, стоимость аренды нормального сервера — от 3 тыс. рублей в месяц. А вы не знали ;)?

    2) Какой бы ерундой вы не занимались — 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор.

    3) Серебряной пули нет. Не важно, какой концепт вы применяете — строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле «PHP для чайников» — ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.


    4) Самый быстрый код — это код, которого нет. И уж точно — когда нет запросов к БД (см. п.1). Так что кеширование — это безусловно то, с чего начинается высокая производительность. Смело забивайте на _любую_ оптимизацию, пока есть возможность что-то закешировать. Закешировать можно все. Вопрос лишь в том, как посылать уведомления о необходимости обновить определенные части кеша. (Возможно кто-то помнит баги сайта free-lance.ru, когда в разных местах одни и те же цифры были разными, из-за чего было много недоразумений. Это позор.) И как правило, чем выше уровень абстракции, тем меньше производительность кода, и тем больше возможность кеширования при тех же затратах человеко-часов. И в итоге на более высокой абстракции можно выжать большую конечную производительность за счет кеширования. Но это уже кто как умеет:) (см. п. 3).

    5) Если вы считаете, что echo быстрее print — вы неудачник. В современных MVC-проектах как правило подобные фичи вызываются как максимум три раза: во front-контроллере, в AJAX-контроллере и в RSS-контроллере — то есть максимум три оператора вывода в стандартный поток на весь ваш большущий проект.

    6) Если вы молитесь на Front-контроллер Zend Framework — это ваше право. Но его концепт "/key/value/" считают революционным люди, не видевшие ничего кроме ?key=value&foo=bar, но кто-то заюзал концепт /virtdir1/virtdir2/virtfile/, используя грязные хаки ERROR 404, задолого до повсеместного появления на виртхостингах (и очень задолго до появления VDS) mod_rewrite (и PHP5;). Конечно, фронт-конроллер ZF очень гибкий, но не легче ли написать свой? Все вышенаписанное справедливо только для больших проектов, если вы пишете много маленьких — это не для вас (заюзайте стандартный Front Controller ZF и сосредоточтесь на легкости поддержки).

    7)
    echo «preved $foo $bar»;
    echo 'preved '. $foo. ' '. $bar;
    echo 'preved ', $foo, ' ', $bar;
    sprintf('preved %1$s %2$s', $foo, $bar);
    Вы, как матерый профессионал хайлоада можете с закрытыми глазами сказать, какая конструкция быстрее? Расслабьте анус, батенька — вы неудачник.
    Вы можете точно и аргументированно сказать, какую концепцию выбрать в качестве стандартной в рамках большого проекта — респект.

    8) Забудьте и навсегда пошлите в глубокий анус виртуальные хостинги, как ваш самый страшный сон. Идите и купите себе виртуальный выделенный сервер с правами root за >=150 рублей в месяц. И поставьте туда ваш любимый Debian/Gentoo/FreeBSD, и управляйте им как Root Всемогущий! Отныне вы свободны! :)

    9) Если на вашей рабочей машине PHP работает под Windows — вы нюхаете цветы в противогазе. Если вы хотите стать профессиональным серверным программистом под *nix — смело сносите Windows и ставьте *nix (Linux, FreeBSD, OpenSolaris, etc...) Если такой цели нет — можете запускать *nix-сервер в виртуальной машине (Virtual Box, VMvare, etc...), но пожалуйста, не мучайте PHP — не гоняйте его под Windows…

    10) Если на вашей рабочей машине PHP работает без акселератора — вы нюхаете цветы в противогазе, надетом на респератор, а поверх этих гламурных шмоточек на вас еще надет… ТАНК! Установите уже акселератор, черт возьми! (upd: имеется в виду development-машина)

    11) Если вы считаете, что постигли PHP5 в совершенстве — вы неудачник. Всегда есть, чему научиться. Если вы точно знаете, у кого вам есть чему поучиться — можете дальше не читать.

    12) PHP5 (PHP4 забудьте, как страшный сон!) — очень коварная штука. Людей там слишком много. Большинство программистов находятся на уровне «ниже плинтуса». Причем некоторые из них умудряются писать умные книги (кстати, я до сих пор не видел ни одной нормальной книги по PHP5), и учить людей «тонкостям программирования на PHP» множеством других способов. Научитесь отделять зерна от плевел — то есть чайников от профессионалов, этот навык будет для вас одним из важнейших. Учитесь у профессионалов. Может быть, вы не представляете, сколько можно потерять времени, пытаясь учиться чему-то у чайников (и мне кстати тоже не верьте;)

    13) И не верьте никому, кто заявляет, что PHP5 — «плохая» технология, пока не врубитесь в нее хотя бы на 90% и точно не будете знать, чего вам в ней не хватает ;)

    upd: Естественно, все вышеизложенное относится к тем проектам, где есть хоть какая-то сложность и нагрузка.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 287

      +11
      С чувством юмора и по сути
      • UFO just landed and posted this here
          +1
          Да. Такое можно про любой язык накотать.
          Это всяко лучше, чем разводить холивар.
            +1
            Это же каким извергом надо быть, чтобы советовать переходить с Windows сразу на OpenSolaris.
              +1
              Зачем на солярку сразу. Можно и Ubuntu поставить. Все зависит от целей.

              Я, работая под виндой, сам периодически сталкиваюсь с проблемой "совместимости" кода. Пока это только упирается в кодировки, однако, бывают и другие нестыковки.
          0
          смешно :) а особенно, как только вспомню людей, что _действительно_ в чем-то так думают

          но честно - мне хочется верить, что профессиональные пхп кодеры есть, но в чем я теперь уверен - он должен знать пхп далеко не как первый язык...
            –2
            >> _действительно_ в чем-то так думают
            Что, сразу все 13 мыслей именно так и думают? :)
              –2
              а вы, уважаемый автор, какие еще языки кроме php знаете?
              +4
              профессионалу глубоко безразлично как написан проект, профессионал может заставить любой код работать с минимальными исправлениями. Все профессионалы - ленивы. ООП язык для ленивых. Профессионалу проще написать одну функцию чем 15 классов и один класс вместо 15 функций. Профессионал знает чего он стоит и получает больше. Лучше быть профессионалом в PHP чем говнокодером на JAVA, хотя лучше стремится познать все :)
                0
                Описание не профессионала, а помеси супермена с планокуром :)

                И как проект написан ему безразлично, и любой код он может заставить работать, и ленивый, и ООП - именно для него, но в то же время ему "проще написать одну функцию", хотя тут же лучше класс, чем функции. И получает он больше, чем стоит, и (вот ведь чудо!) - лучше ему быть профессионалом, чем говнокодером.

                Бред какой-то.
                0
                Мб, и первый подойдет. Но, имхо, очевидно, что при прочих равных, хорошее знание еще нескольких языков полезно. Вообще, чем больше знаешь, тем полезней. Вопрос в том, как найти баланс между кругозором и глубиной знаний.
                +3
                пошел уговаривать админа поставить акселератор...
                  +2
                  1) не понял про что пункт
                  2) согласен полностью. + надо еще умудриться заставить выбранный акселератор остаться в живых при большой нагрузке. Страшный сон этого пункта - segmentation fault
                  3) парадигмы применяются не для непосредственного увеличения производительности. Скорее, для более удобной реализации механизмов увеличения производительности (тот же кэш)
                  4) согласен
                  5) супер! :))) 5+
                  6) не работал с этим фреймворком
                  7) 5+
                  8) теоретически согласен
                  9) не согласен. Точнее, не всегда это так. В большинстве случаев это не так.
                  10) то же самое
                  11) согласен.
                  12) не РНР5 - коварная штука, а комьюнити РНР5 - коварная штука.
                  13) блин, вот это профессионально!
                    +2
                    1) Пункт про то, что PHP как правило не является узким местом и возможно не стоит так гнаться за производительностью PHP, а вместо этого заняться более адекватными вещами...
                    3) Да. Просто топик изначально писался в контексте высокой производительности, да еще эти вечные советы по ускорению PHP с помощью правильных блох... :)
                    10) Без акселератора на машине разработчика вообще не стоит говорить об оптимизации - профайлер будет бессовестно толкать вас на такие жуткие вещи, как например вырезание комментов :) вместо оптимизации _действительно_ узких мест.
                    9) После п.10 уже не актуально :)
                      0
                      1) см. ниже
                      9), 10) убедили :) согласен.

                      А вообще, по поводу "вечных советов по ускорению PHP с помощью правильных блох" полностью поддерживаю. Писал об этом буквально вчера
                        0
                        а что насчет второго пункта? segmentation fault... он же есть...
                          0
                          это проблемы кривизны акселератора...
                            0
                            Это ненормально. Нужно добиться того, чтобы его не было.
                              0
                              Используйте APC и ваши волосы будут мягкими и шелковистыми.
                          0
                          по мне дак не очень статья :) мне кажется через чур уж юморно, но, стоит отдать должное, полезная инфа ;)
                            +11
                            Есть полезная информация, но многочисленные "вы неудачник", "цветы в противогазе" и т.д. вызывают отторжение. Было бы гораздо лучше, если бы вы написали эту заметку как статью.
                              +3
                              О статье, которых миллионы, забудете через неделю. А цветы в противогазе и акселератор в расслабленном анусе запомнятся надолго.
                                +8
                                Чтобы статья запомнилась, попала в закладки, на рабочий стол, на принтер - она должна быть полезной, а не запоминающейся.
                                Я бы добавил этот пост в закладки, если бы здесь было в два раза больше полезной информации и почти не было шелухи про противогазы и анусы - это мерзко и неприятно.
                                  0
                                  Возможно. У каждого ведь свое восприятие и методы сохранения полезной информации. У кого-то в закладках, у кого-то в собственной памяти. Кому-то достаточно идею запомнить, а кому-то надо детали записать. Так что свое мнение не навязываю, просто высказал :)
                                    +1
                                    :)
                                    Разумеется. Мы ведь просто обсуждаем.
                                  0
                                  Прочел. Через 5 минут решил вспомнить. Но помню только противогаз, анус и цветочки. Не понял почему там был PHP?

                                  Решил перечитать и наткнулся на такие вещи
                                  > Если на вашей рабочей машине PHP работает под Windows ... не мучайте PHP - не гоняйте его под Windows
                                  Что есть в винде и чего нет в юниксах, от чего PHP становится мучительно работать?
                                  Чем плоха винда в данном случае?
                                  Что вы не можете сделать такого на винде, чего можете на юниксах?
                                    0
                                    Я тоже "мучаю" дома и на работе php под windows, ещё "издеваюсь" над php на выделенном, виртуальном выделенном и просто виртуальном хостингах под *nix и что-то до сих пор не заметил разницы в работе под этими платформами.
                                      –5
                                      Позабавил такой момент.
                                      Автор очень часто использует "яркие" выражения со словами "анус", "противогаз" и проч..
                                      Но он тщательно выводит с большой буквы "Windows" вместо ставших привычными в статьях подобного сорта "вынь", "сукьс", "масдай" и проч.

                                      В результате очень сомнительной впечатление от прочтения статьи :)
                                        –13
                                        больше!
                                        больше минусов!
                                        еще больше!!!!

                                        и я уйду отсюда - к черту этот ресурс
                                          +3
                                          а вы хотите чтобы автор слово "анус" с большой писал? О,Анус....
                                        +1
                                        Что вы не можете сделать такого на винде, чего можете на юниксах?

                                        Сразу вспоминается то, на что наступали.
                                        1. Стереть открытый файл.
                                        2. Использовать flock как рекомендательный лок, а не жёсткий.
                                        А вообще мелких отличий - десятки, а то и сотни. Именно что получается "запах цветов в противогазе": основные вещи-то те же, но никогда не знаешь - будет оно в боевом режиме работать так же или нет. Можно, конечно, и на сервер Windows взгромоздить - но тогда уж лучше использовать Windows-технологии (ASP.NET, etc).
                                          +1
                                          Я а не думаю что автор так уж презирает Windows. Упор скорее на то, что использовать разные столь среды для разработки и для продакшна - самому себе создавать проблемы. Одно дело FredBSD vs Linux: с высоты PHP-шных абстракций отличия можно заметить раз в сто лет, другое - Windows vs *nix: отличий - вагон и маленькая тележка.
                                            0
                                            Это все очередные частности превосходства одного перед другим.
                                            каждый юникс имеет множество отличий друг перед другом.
                                            Я же говорю в общем.

                                            Неужели [b]с точки зрения автора[/b] в винде нельзя написать приложение, которое будет работать одинаково хорошо как в винде так и в юниксах.
                                              +1
                                              Наверное я не совсем ясно выразился. Скорее всего в винде все будет работать примерно так же, как в никсах, но не ждите, что профайлер покажет вам те места, которые будут реально узкими на боевом серваке. Хотя примерно - да.

                                              Но главное - вы отделяетесь от никсов, вы не видите всю систему в целом. Речь здесь идет о хотя бы мало-мальски нагруженных системах, так что руку нужно держать на пульсе постоянно.
                                              • UFO just landed and posted this here
                                              0
                                              + однажды пытался распараллелить выполнение пхп скрипта на несколько потоков (знаю что это перебор и гораздо лучше был бы тот же перл/питон, но так было удобнее для комплекса)
                                              под _W_indows сие чудо работать не могло. под *nix же, что называется, с пол-пинка
                                                0
                                                знаете, насчет противогаза и прочего, сразу видно, что человек рассматривает php только как веб язык. Его же еще можно использовать как аналог перловки или питона. Я согласен, что многие фичи из никсов не работают, но например когда мне нужно было написать маленький импортер из mysql в excel, я тупо заюзал com и не е@ся с пировскими и прочими библиотеками(кстати никто не знает нормально создающую библиотеку без косяков с русской кодировкой?пировскую библиотеку при setVersion(8) сколбашивает).Так что вы неправы ;) и там и там пхп к месту, главное не пытаться заставлять его делать то, для чего он не предназначен :)
                                                  0
                                                  > "Его же еще можно использовать как аналог перловки или питона."
                                                  Не ради холивара, но, уважаемый, вы скорей всего очень мало сталкивались с указанными языками и перлом в частности. Не стоит делать таких громикх замечаний :) PHP - PHP Hypertext Processor и этим ве сказано, в других местах он слаб, да и не нужен он в других местах.
                                                  > "когда мне нужно было написать маленький импортер из mysql в excel"
                                                  попиарю еще немного перл :) А вот то, что отвечает вашей задаче в точности.
                                                    0
                                                    кстати последнее есть и под php (импортировано из perl) и без всяких пиров
                                                0
                                                Чем плоха винда в данном случае?

                                                в силу обстоятельств сейчас вынужден возиться с ПХП и Zend Framework.
                                                дык вот, на моём ноуте стоял денвер, под ним и начал возиться. при чем так, в спешке, не заморачиваясь над производительностью. потом чисто случайно замерил время отработки скриптов и ужаснулся. потыркал профайлером и чуть дар речи не потерял. bootstraper отрабатывал 0.3с (три_десятых_секунды!!!). при таком раскладе кроме как отказаться от Zend Framework'овского MVC ничего в голову не приходило, но данный пунктик был на время отложен.

                                                а потом у меня появился свободный вечер и я поднял себе на WMVare линушок, аналогичный тому на котором всё в последствии должно будет крутиться. ну и заодно перенес всё с денвера на виртуальную машину.

                                                и тут, о чудо, всё резко заработало нормально! bootstraper отрабатывает за 0.05, для виртуальной машины (которой я выделил аж 128M памяти и вроде как больше одного ядра она у меня принципиально не отъедает) мне такого показателя вполне достаточно.

                                                возникает вопрос: и почему под виндой оно работало в 6 раз медленнее !?...
                                                  0
                                                  потому что вы профан. во-первых "денвер" - это ужасно, а во-вторых, ВЫБИРАТЬ систему или фреймвор тестировать не под той системой где оно реально будет работать - глупо. Здесь говорили о разработке, а не о тестировании. Общее состояние при разработке под линуксом и виндой одинаково почти. при профилированни надо сравнивать порядки цифр, а не их точные значения.
                                                    0
                                                    потому что вы профан.

                                                    спасибо :")

                                                    во-первых "денвер" - это ужасно

                                                    а что не ужасно? собирать из сырцов под виндой?! :D
                                                    до тех пор пока мне хватает его возможностей он меня устраивает. к тому-же мне не так уж и часто приходится с ним иметь дело :)

                                                    во-вторых, ВЫБИРАТЬ систему или фреймвор тестировать не под той системой где оно реально будет работать - глупо.

                                                    речь шла не о выборе и тестировании, а о случайно замеченном факте. трактовать который можно по разному.

                                                    при профилированни надо сравнивать порядки цифр, а не их точные значения.

                                                    речь не шла о профилировании, до него еще далеко. профайлером я тыкал только для того чтобы выяснить ЧТО тормозит, и когда увидел что тормозит кусок фреймворка то был сильно расстроен. но, как оказалось в дальнейшем, зря.

                                                    поймите, я отвечал на конкретный вопрос: «Чем плоха винда в данном случае?»
                                                    и в ситуации которую я описывал винда была плоха тем, что чуть не стала причиной незаслуженных кирпичей в cторону ZF.
                                                    вы считаете что в «денвере» php или апач сильно отличается от любой другой «подвиндузной» сборки?
                                                      0
                                                      Денвер - это такая поделка, зло которой в том, что Котеров зачем-то половину ДЕФОЛТНЫХ значение php.ini перекрутил на другие. в результате если проект сложный, вы сталкнетесь с большими проблемами на продакшене. Денвер зло, которое приучает писать неправильно и с костылями. А потом приходят такие вот на работу и ставят себе денвер и удивляются когда я присылаю бумажку с просьбой поставить тот или ино модуль новый. Они просто не знаю что это такое!

                                                      Что до остального - подчеркну - мы говорили О РАЗРАБОТКЕ и отдельные тормоза какой-то там фигни совершенно на разработку не влияют. Ваше удивление говорит лишь о том, что ВЫ НЕ ТЕСТИРОВАЛИ свой выбор фреймворка, а тупо начали им пользоваться. Это не вина винды или еще чего. Если бы вы осмысленно выбрали фреймворк, оттестировали его как положено, то данные конкретные тормоза вам были бы безразличны - потому что вы ЗАЛИ БЫ как он на самом деле работает. И тогда сосредоточились бы не на отладке чужого кода, а всетки на разработке и тестировании своего. Надеюсь я достаточно развернуто ответил?
                                                        0
                                                        и удивляются когда я присылаю бумажку с просьбой поставить тот или ино модуль новый. Они просто не знаю что это такое!

                                                        а... ну в таком контексте да... тут сложно спорить :D

                                                        Ваше удивление говорит лишь о том, что ВЫ НЕ ТЕСТИРОВАЛИ свой выбор фреймворка

                                                        в точку. я собирался с ним познакомиться.

                                                        Если бы вы осмысленно выбрали фреймворк, оттестировали его как положено, то данные конкретные тормоза вам были бы безразличны

                                                        если бы бабке писюн, она дедкой была бы :D
                                                        вот так соберешся поиграться с чем-то, а потом выводы неправильные сделаешь. и не потому что я не ЗНАЛ, я ведь как раз собирался УЗНАТЬ, а потому что неправильно выбрал платформу для игр.
                                                        в таком контексте понятно почему винда не есть лучший выбор с моей точки зрания?
                                                          0
                                                          Это все условности и частности. Никакого особого отношения к винде, в частности, не имеющие. Не вижу никаких проблем разработки в винде. Я вот сижу под линуксом - просто привык и обкатываю новые технологии, но у меня работа такая. Программеры в массе своей сидят в винде - и никаких проблем не было никогда.
                                                          0
                                                          Денвер не зло. Зло использовать денвер для чего либо кроме начального обучения. Ни кто не мечтает научиться конфигурировать АПАЧ, а сайт желают сделать каждый продвинутый ШКОЛЬНИК. Денвер поделка на уровне Школьника. Если ее использовать для чего либо другого тогда да. А в Школе он помогает.
                                                            0
                                                            Сколько меня не лечи - я считаю что денвер зло. И вот почему: первый же запрос в яндексе дает ссылку на такое детальное и простое описание "как поставить LAMP" что это становится ничем не сложнее денвера, а необходимый навык получается. К тому же, главная претензия к денверу в том, что там умолчательные настройки поменяны на черте какие и навешено столько левой фигни, что часто программист нафиг не способен понять почему дома у него работает, а на работе нет - потому что всяких длл там понапихано левых немеряно.
                                                              0
                                                              Извините. Я никого не соберался лечить и агитировать за денвер. Это образовательный проект. И он РЕАЛЬНО мне помог учить детей.
                                                              Как только мы прошли азы, начались проблемы. В ДИЗАЙНЕ его использовать нельзя. А LAMP это линукс апач мускул ПХП?
                                                              Это не очень подходит для начального обучения. Нельзя сразу объяснять и материал и еще 4 программы.
                                                              А вот куроводство по моему мнению зло. Всмысле - личное мнение с притензией на абсолютную истину - это всегда зло.
                                                          0
                                                          уж лучше XAMPP
                                                  0
                                                  А по-моему удачно написано. ухую псевдо-научную статью возможно не каждый бы дочитал до конца.
                                                  Это как лекция в университете, в течении которой преподаватель только монотонно бубнит, склоняя тудентов ко сну :)
                                                    0
                                                    Тут на любителя, каждому своё :)
                                                  0
                                                  полезные мысли, стоит над ними периодически медитировать (читай задуматься).
                                                  но автору-- за способ изложения.
                                                    +8
                                                    Читаю комментарии, и ужасаюсь. Для написания данной статьи мне понадобилось: 2 противогаза, 2 ануса, 1 танк и 3 (!) неудачника! Впредь обязуюсь соблюдать следующие нормативы: на один хабратопик не более: 1 противогаза, 1 ануса, 1 танка и 1 неудачника! :)

                                                    Однако плюс от применения танков, противогазов и анусов налицо:
                                                    1) Никто не заметил в п.5 - "три оператора вывода" - print() - не оператор, а функция. Никто не добавил, что на один HTTP запрос отвечает один оператор echo (или функция print():)
                                                    2) В п.4 - "Закешировать можно все. Вопрос лишь в том, как посылать уведомления" - никто не стал спорить о вероятности попадания в кеш.
                                                    3) Никто не сказал, что пример в п.7 плох на фоне п.5 :)

                                                    Ну и еще там есть... В общем противогазы и анусы намного популярней PHP даже в блоге про PHP ;)
                                                      0
                                                      AirWorker, до этого еще не добрались :) там еще полно чего. Просто противогазы интереснее в первую очередь обсуждать, пока мозг обдумывает более важные вопросы
                                                        +1
                                                        К моменту, пока доберутся до важных вопросов топик будет так засорён, что найти их буднет на фоне противогазов и анусов нельзя.
                                                        0
                                                        А еще поправки иногда выливаются в бубнеж под нос, а не в комментарии с обличением :).
                                                          0
                                                          это как раз говорит об уровне знаний php-программистов :-)
                                                          PS: прошу всех не воспринимать лично — шутка...
                                                            0
                                                            Потомучто в этой откровенно замской статье, все остальное было не важно. автору очень понравились пошлые метафоры и он ими упивался. А содержание оказалось не важно. Я лично поставил - статье, потому что содержание должно соответствовать оформлению, а тут на лицо расхождение.
                                                          • UFO just landed and posted this here
                                                              0
                                                              у Zend_Controller_Front есть такая замечательная вещь как маршрутизаторы ;)
                                                                0
                                                                Да. Но слишком сильная заточка под /key/value/ (концепт /vdir1/vdir2/vdir3/ реализуется некрасиво)
                                                                  0
                                                                  почему же, можно настроить и на "концепт /vdir1/vdir2/vdir3/" и на какой угодно = ), Zend_Controller_Router_Route_Regex на самом деле творит чудеса = ) тем более что доступ ко все переменным запроса идет через объект Request.
                                                                    0
                                                                    Может и зря я здесь пункт про ZF-контроллер ввернул... Эта тема уж очень специфическая.
                                                                    В общем решение есть, но не все так гладко, как бы хотелось...
                                                                      0
                                                                      Красота требует времени и жертв ;)
                                                                      Так, что напильник в руки иии.. хотя я думаю, уже есть готовые решения на этот случай ?
                                                                        0
                                                                        Так никто не заставляет использовать родной зендовский контроллер, можно свой написать, о том и речь ))
                                                                    0
                                                                    Некрасиво, факт. Потому что всё остальное так или иначе заточено под формат "модуль-контроллер-действие", тогда как троичность этой конструкции весьма условна. Но делать нечего, корячимся...
                                                                      0
                                                                      Контроллер ZF очень сильно универсален. В большом проекте можно написать свой контроллер попроще.
                                                                  +1
                                                                  Всё же меня всегда удивлял такой подход к делу: возьмём не самые быстрые технологии для хранения данных, не самый эффективный по производительности язык программирования, а потом начнём все оптимизировать... То есть, я тут не наезжаю ни на кого, меня эта ситуация просто удивляет. Наверняка я чего-то не понимаю.
                                                                    0
                                                                    Вы знаете более быстрые языки для веб программирования?
                                                                      0
                                                                      Смотря что считать web-программированием. Я, конечно, совсем не специалист в этом, но для меня web-программирование - это обмен данными с пользователем через http. И только.

                                                                      Остальная часть - это просто программирование во всём его многообразии. А для разнообразного программирования есть множество инструментов с производительностью готовых программ намного превосходящей готовые программы, созданные при помощи связки php + база данных.
                                                                        0
                                                                        А что такое "язык для веб-программирования"? Я за последние лет 5 участвовал в создании не одного веб-проекта. Использовалась C++ и Java в основном. PHP - один раз для вспомогтельного сайта. Считать ли Java языком веб-программирования?
                                                                          0
                                                                          Ява.
                                                                          Возможно, мод_перл.
                                                                            0
                                                                            Вы учитывали скорость разработки в оценке? Даже если PHP в этом случае несколько медленнее, то на сэкономленные на зарплате программистов деньги (т.к. выше скорость разработки и ниже ее сложность) можно установить немного более мощный сервер, на котором все будет работать не медленнее.

                                                                            Еще я слышал, правда из не очень авторитетных источников, что PHP с оптимизатором не уступает Яве по производительности.
                                                                              –1
                                                                              Ну, вопрос же был именно про скорость исполнения.
                                                                              Но раз уж вы про скорость разработки...
                                                                              Чем скорость разработки на яве меньше скорости разработки на пхп??? Я занимался и тем и другим. Мой опыт показывает, что на пхп существенно медленнее из-за тошнотворного синтаксиса, [список прочих общеизвестных уродств пхп] и существенно худшей поддержки со стороны IDE.
                                                                              Перл я сильно трогать не буду, давно это было... Но тоже не понимаю где там могут быть тормоза со скоростью разработки. Писать на перле приятнее, чем на пхп :). Если не лезть в дебри, то писать на перле можно в очень похожем на пхп стиле, учитывая то, что пхп и был рождён как очень сильно усечённое подмножество перла с косметическими отличиями :). Если не касаться ОО, конечно. Как сейчас в перле с ОО я не в курсе, а во времена оны было, конечно, за уши притянуто и не сильно просто в использовании. Если так и осталось, то да, тут перл по скорости и удобству разработки проиграет, наверное.
                                                                          0
                                                                          любую технологию надо оптимизировать и "подтачивать" под под определенные нужды, если ничего этого не делать, даже самую хорошую технологию и самый лучший язык можно превратить в нечто ужасное, я думаю.
                                                                            0
                                                                            Да. Но у php + bd есть явное ограничение сверху на степень заточенности.
                                                                              0
                                                                              "ограничение сверху на степень заточенности" — уж слишком абстрактное понятие; идеализировать любой инструментарий людской деятельности можно (в теории, и в попытках — на практике) бесконечно (на протяжении жизни человечества), но, жить и работать нам с вами нужно сейчас и сегодня... сейчас и сегодня...

                                                                              Многие очень крупные компании нисколько не пугаются использовать связки php+mysql, python+postgre и другие варианты, пока эти связки работают и решают насущные задачи...
                                                                            +3
                                                                            Проблема не в производительности языка, а в том кто и как пишет приложения, слишком низкий проходной уровень языка - это и проблема и успех самого языка, т.е. если перенести это какой-нить абстрактный язык это выглядело бы это так:
                                                                            - программист выучил Java/C#/C++ за 24 часа по книге для чайников
                                                                            - ему ставят задачу написать программку для работы с БД (какой-нить телефонный справочник)
                                                                            - все работает, но с увиличением кол-ва записей начинает программа загибаться, т.к. юнец для того чтобы посчитать кол-во записей в таблицах - выгребает все записи, а потом считает кол-во итемов в массиве путем перебора цикла(1)
                                                                            - но "мега гуру" говорят - да ты вот этак сделай перебор цикла будет на ХХ% быстрее (это про блошиную оптимизацию - 5 и 7)
                                                                            - после приходит реальный гуру, находит сие неподобство, объясняет что да как, а заодно и говорит, что при компиляции лучше выставить такие-то галочки - т.к. их нужно всегда выставлять для финальной компиляции - и будет быстрее работать (это по пункту 10)
                                                                              0
                                                                              Ну. Если на всё именно в таком свете смотреть, то согласен.
                                                                          • UFO just landed and posted this here
                                                                              +1
                                                                              рабочая это имеется ввиду production сервер как я понял :)
                                                                                0
                                                                                сначала прочитал как development, но потом понял что все же про production идёт речь в 10-м пункте.
                                                                                0
                                                                                ну насчет персистентных коннектов к базе можно поспорить.
                                                                                Во-первых, они работают только когда PHP установлен как модуль Apache, что не всегда хорошо.
                                                                                Во-вторых, чтобы нативно работать с MySQL 4.1 и новее без использования старых методов авторизации и устаревших функций, нужно использовать MySQLi расширение/функции. Они не поддерживают постоянные соединения, увы. Как и интерфейсы ко многим другим СУБД. Поэтому вся оптимизация работы с БД идет через правильные и оптимизированные запросы и уменьшение их количества.
                                                                                Насчет акселераторов - согласен.
                                                                                  0

                                                                                  А как же PDO??

                                                                                  PDO::ATTR_PERSISTENT => true
                                                                                  0
                                                                                  0. ... и комментарии.
                                                                                  1. Запустите профайлинг любого вашего проекта, который работает с БД. Я готов поспорить, что время работы с БД будет занимать не меньше половины времени работы скрипта
                                                                                  2. про оптимизатор и опкод это в догонку к предыдущей статье, где всякими извращениями над исходных кодом пытались его "оптимизировать".

                                                                                  Автору: Молодец, согласен со всем, кроме обустройства девелоперской машины. Год проработал с LAMP в vmWare, вспоминаю как страшный сон. Денвер намного практичнее и удобнее. И не понятно зачем _разработчику_ акселератор. Быстрее он от этого писть не будет, точно
                                                                                    +1
                                                                                    >> И не понятно зачем _разработчику_ акселератор. Быстрее он от этого писть не будет, точно
                                                                                    Окружение, приближенное к боевому на девелоперской машине нужно по одной простой причине: для постоянного контроля реальной (близкой к реальной) скорости и вычисления узких мест "на лету". Вы должны всегда быть в курсе, что происходит в общей системе сервера и как работают его части вместе.

                                                                                    Топик написан все же с прицелом на высокую производительность.
                                                                                      0
                                                                                      Создавать на компе или ноутбуке разработчика то же окружение, что и на сервере глупо.
                                                                                      Есть хорошее правило - публикуй проект на сервере как можно раньше. Это позволяет:
                                                                                      1. быстро находить и устранять проблемы несовместимости проекта с окружением,
                                                                                      2. привыкнуть к циклу обновления приложения на сервере
                                                                                      3. оценивать производительность приложения

                                                                                      И не будет проблем, что 2 месяца создавал проект, а он потом не заработал.
                                                                                      • UFO just landed and posted this here
                                                                                          0
                                                                                          Так ничто не мешает в отладочном домене публиковать.
                                                                                          0
                                                                                          Удаленная отладка гораздо медленнее и сложнее в настройке (иногда - невозможна)... Или вы правите в блокноте???
                                                                                          0
                                                                                          "Преждевременная оптимизация — самое большое зло", — Д.Кнут.
                                                                                          Вначале разработка. Когда решите оптимизировать, тогда уже можно держать включенным оптимизатор и профайлер постоянно.
                                                                                            0
                                                                                            Никто не заставляет вас оптимизировать сразу. Но знать сразу где что тормозит - очень полезно.
                                                                                          –1
                                                                                          > Я готов поспорить, что время работы с БД будет занимать не меньше половины времени работы скрипта
                                                                                          Вы проиграете... При использовании фреймворков до 60% (в особо экстремальных случаях) занимают require_once
                                                                                          +1
                                                                                          >> персистент коннекшен к базе снижает накладные расходы почти до нуля - дальше все зависит от ваших познаний БД.
                                                                                          Похоже вы нашли серебряную пулю :)

                                                                                          >> козе боян? на моей рабочей машине я хочу отлаживать код, а не акселерировать
                                                                                          Отлаживайте, тестируйте, вылавливайте баги, но об оптимизации забудьте
                                                                                          –2
                                                                                          Может быть, отсутствие трудосустройства у автора даст ему повод задуматься, почему ему не нужно выставлять свою эгцентричность напоказ.
                                                                                          0
                                                                                          хех, со здоровым юмором и по больному месту :)
                                                                                            0
                                                                                            такое впечатление что автор помахал красной тряпочкой перед php-программистами и хочет поиграть в торреодора
                                                                                              0
                                                                                              не перед программистами.
                                                                                              а перед толпами идиотов, калякающих говносайты методом копи-паст.
                                                                                              0
                                                                                              пункты 11 и 13 друг другу противоречат - это раз.
                                                                                              Если кто-то соответствует пункту 13 - пишите!!! звоните!!! предлагаю зарплату в 10 000$!!!
                                                                                                0
                                                                                                судя по всему они дополняют друг друга, а не противоречат
                                                                                                0
                                                                                                автору респект и уважуха :)
                                                                                                  0
                                                                                                  Со многими пунктами не согласен.
                                                                                                  В частности, пока есть что оптимизировать и что даст после оптимизации значительный прирост производительности - нужно оптимизировать. И только потом прибегать к кешированию. Ибо кеширование - не всегда хорошо (например, данные могут обновляться так часто, что кеш будет перестраиваться не реже или ненамного реже, чем загрузка страницы с этими данными - смысл тогда в кеше?), а реализовать его иногда бывает сложнее, чем оптимизировать несколько участков кода. Поэтому правильный путь нужно выбирать по ситуации, а не сразу кидаться кешировать все и вся.
                                                                                                    +2
                                                                                                    Статья-источник про советы по оптимизации скорее носила ознакомительных характер, аля Оптимизация программ на PHP без изменений алгоритмов от Бородина. Причем ключевое слово тут «изменений» и «алгоритмов».
                                                                                                    кеш, акселерация и прочее это, несомненно, очень хорошо =) просто мега хорошо и порой действительно спасает. Но не стоит забывать о оптимизации алгоритмов, на каком бы языке они небыли бы изложены. В последнее время много выскочек пропагандируют кеши и акселерации, а в итоге народ с сертификатом повышения квалификации из Бауманки пишет полнейший говнокод, который спасает только кеш и если кеш слетает (а слетает он часто на хороших нагрузках. Скажем, на одном из моих проектов 20 серверов с мемкешем, частенько то один то другой виснут) говнокод валит сервак.

                                                                                                    Люди, изучайте кеширование и акселерацию только тогда, когда у вас уже возникли проблемы с нагрузкой и вы уже потратили минимум пару недель на оптимизацию алгоритмов. Иначе станете говнокодерами, а не программистами.
                                                                                                      +1
                                                                                                      т.е. вроде ООП переболели, если год назад я бы заявил что ООП отстой и можно обойтись статическими классами и процедурами на худой конце — меня все банили, то теперь просто минимуют по тихой. Выросла новая болячка — кеш =) теперь все считают что панацея это кеш.
                                                                                                        0
                                                                                                        Обойтись чем-то "более простым" можно всегда, не вопрос:)
                                                                                                        Но разобраться в этом более простом через 2 месяца будет уже невозможно.
                                                                                                          0
                                                                                                          Как в той рекламе: «ты просто не умеешь их готовить». Если за 2 месяца ты не можешь разобраться в своем коде, то о чем можно говорить.
                                                                                                            0
                                                                                                            ... а в чужом? :) Глобализация уже в полный рост имеет место: фреймворки там всякие и пр.

                                                                                                            Как известно, ОО* - это больше средство повторного использования кода. Имеется ввиду, повторного использования другим человеком. Т.е. - это больше некие репрезентативные функции. И это ОО-подходу вполне удается. Я не очень представляю себе Zend Framework в не-ОО исполнении. Хотя нет - представляю. Получится как раз такая лапша, за которую многие так не любят php. Конечно, можно сделать так, что это все будет работать, но...

                                                                                                            В связи с этим вспоминается нашумевший тут диспут :) по поводу правильной настройки винды, что б не падало и не глючило. Лично я предпочитаю не бороться с тем, чего можно избежать.
                                                                                                              0
                                                                                                              Повторное использование кода? Для этого существует документация и структуры, которые, кстати, очень активно юзает ОО подход. Те же классы не имеют отношения к ОО, пока на основе их не строятся объекты. Организовав статичные классы мы имеем те же плюсы для вас — неймспейсы по сути, плюс отказываемся от объектов.
                                                                                                                0
                                                                                                                И всего этого гемороя можно счастливо избежать.
                                                                                                                По крайней мере мне - удается :)
                                                                                                                  0
                                                                                                                  геморой вы зарабатываете, а не избегаете.
                                                                                                                  Я дела:
                                                                                                                  1. Разработавыю класс
                                                                                                                  2. Работаю с ним.

                                                                                                                  Вы делаете:
                                                                                                                  1. Разрабатываете класс.
                                                                                                                  2. Не забываете объявлять объекты на основе класса.
                                                                                                                  3. Работаете с объектом.
                                                                                                                    0
                                                                                                                    :) Моя схема работы совсем не совпадает: я предпочитаю начинать сначала - с проектирования...

                                                                                                                    Если делать именно так, как указано у Вас - да, это сложно. Потому как потом начинается бардак и анархия: обязательно что-нибудь забываем :)

                                                                                                                    Есть основное отличие в подходах, на котором мы никогда не сойдемся: организация мозгов. ОО требует большей строгости, но я хорошо знаю, что лучше сначала два часа подождать, за то потом - за 5 минут долететь. И потом уже летать неоднократно :)
                                                                                                                      0
                                                                                                                      возможно в чем-то вы правы.
                                                                                                                      Ваши самолеты меняются редко, чаще доделываются.
                                                                                                                      Мои чаще делаются под конкретный полет. Действительно это некоторые временные затраты перед каждым полетом, однако и голова у меня работает чаще.
                                                                                                        0
                                                                                                        Эту статью можно прочитать один раз и забыть, она еще для PHP3 кажись писалась, и уже давно не актуальна!!!
                                                                                                          0
                                                                                                          Как и те 40 советов, диззом на которые является эта статья. Дело не в этом.
                                                                                                      • UFO just landed and posted this here
                                                                                                          0
                                                                                                          нераскручен. точнее, не так раскручен, как ZF.
                                                                                                            0
                                                                                                            Просто разработчики ZF могут при надобности и PHP подправить под свои нужды...
                                                                                                          0
                                                                                                          Ну зачем да так сразу - неудачник. В команде должен быть 1 человек, который хорошо знает тонкости php, чтобы соптимизировать framework. А потом да, потом нафиг такую оптимизацию.
                                                                                                            0
                                                                                                            Хороший ответ на все последние статьи в блоге РНР:
                                                                                                            1. задолбали "оптимизаторы",
                                                                                                            2. достали "мастера" со примерами своего "ООП" кода.

                                                                                                            Исключая пункты про хостинг, мою рабочую станцию (да, да, винда :) и авторов книг о РНР (Котеров вполне сойдёт), в основном согласен.

                                                                                                            Сам взялся писать подобный топик, но автор опередил. За что ему респект и уважуха.
                                                                                                              0
                                                                                                              В фавор. И - на ночь читать.
                                                                                                                –5
                                                                                                                1. "узкое место _всегда_ - БД." - Если руки из ЖОПЫ , то ДА оно.
                                                                                                                2. "Какой бы ерундой вы не занимались - 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор." - см. пункт 1, я не применяю акселераторов, код получаеться все ровно быстрый.
                                                                                                                3. ООП - едиственный правельный метод написания, кроме


                                                                                                                • Вы школьник

                                                                                                                • Вы пишите только для себя

                                                                                                                • Вы не будите никогда приметь этот код

                                                                                                                • вы никогда не смотрите, на то , что написали(если нужна новая ф.(дада, ни клас и ни метод, а иммено ф. так как вы не пишите на ООП) вам проще написать заного ее, опять отловить все ошибки во время ее написания )



                                                                                                                4. 5 пункт , я вообще не понял, о чем Афтар говорит(RSS-контроллере Это что за зверь).
                                                                                                                5. Пункт 8 справедлив лиш в том случае если совокупный доход раза в 4 больше платы за сервак.
                                                                                                                6. 10 пункт, я уже говорил, у меня на 100 проц. движок динамичный. кеш не нужен, так как у меня нет статичных объектов в принципе(не надо меня шпынять за это, я сам выбрал гибкость в упор статике ).

                                                                                                                интернет бизнес
                                                                                                                  0
                                                                                                                  1. Оно узкое место, как раз если руки не из ЖОПЫ.
                                                                                                                  3. Этим надо переболеть
                                                                                                                  4. А вы rss отдаете контроллером, который отдает обычную версию сайта?
                                                                                                                  5. Зарплаты растут, серваки дешевеют. Смотрим в будущее.
                                                                                                                    0
                                                                                                                    1. я знаю решения, на окторых 10 пользователей умирало в виду, что каждое обращение к базе убивало сервак на 100 проц.
                                                                                                                    3. не понял
                                                                                                                    4. рсс - это лента новостей ?, если да, то у меня есть XSLT шаблон и XML(данные с сайта), я трансформирую получается лента, какой контроллер то ?
                                                                                                                    5. люблю знаете ли работать на себя.
                                                                                                                      0
                                                                                                                      1. Если руки из ЖОПЫ, то любое место - узкое.
                                                                                                                      3. Просто ООП не панацея, есть случаи, когда его не удобно применять.
                                                                                                                      4. Рсс это не обязательно лента новостей(Точнее даже это совсем не лента новостей). Довольно часто приходится немного разные данные использовать в рсс и самом сайте.
                                                                                                                      5. VPS-ка простая стоит 150 рублей, это как надо программировать, чтобы доход был меньше 600 рублей?)
                                                                                                                        0
                                                                                                                        1. +1
                                                                                                                        2. ооп удобен. я уже не могу писать без него(просто по 8 летнему опыту говорю)
                                                                                                                        5. - я говорю про выделеный сервак - 2к в мес., его можно позволить себе если у вас 1-2к в день))))
                                                                                                                          0
                                                                                                                          2. Ну это же все субъективно. Да и холивары мне надоели)
                                                                                                                          5. Ну дык в оригинальном топике то про впс-ку говорилось.
                                                                                                                    0
                                                                                                                    хороший запрос отрабытывает 0,01 секунды.
                                                                                                                    узкие же места, о которых говорит автор - разница между кавычками, единицы тактов процессора. по сравнению с ними БД - действительно узкое место.
                                                                                                                    понятно?
                                                                                                                      0
                                                                                                                      Вы еще щас скажите, что все сайты надо делать статикой, так как она еще быстрее ))))
                                                                                                                        +1
                                                                                                                        Вы невероятно близки от истины.
                                                                                                                          0
                                                                                                                          Нуну ) и перестраивать всю динамику с каждым изменением в статику )
                                                                                                                            0
                                                                                                                            Не надо крайностей. Зачем всю ? Достаточно редко меняющуюся.
                                                                                                                          0
                                                                                                                          Что за мудацкий комментарий?
                                                                                                                          Ты вообще врубаешься в то, что читаешь? Речь не о том, что использовать, а что оптимизировать.
                                                                                                                        0
                                                                                                                        с каких пор ООП - _единственный_ правильный метод?
                                                                                                                          +2
                                                                                                                          с таких, что с ооп намного удобночитаемый код.
                                                                                                                          у меня работа связана с разбором говнокода, и получается , что очень много когда написаного разными людьми мне приходится просматривать и обрабатывать, отсюда то и говорю.
                                                                                                                            +2
                                                                                                                            В пределах одной компании (группы разработчиков) отлично решается путем введения жёстких требований к оформлению кода - как именовать переменные и функции, как форматировать код и т.д., у меня например такое требования занимают три экрана 1280х1024 10-ым шрифтом :) Не хочет программист-исполнитель соответствовать этим требованиям, мотивируя тем что "мне удобнее писать так" - придется с ним расстаться. Это _хороший_ подход и он _работает_. И код получается не менее хорошо читаемым чем при ООП. Он просто - _другой_. А другой - не всегда значит плохой.
                                                                                                                              –3
                                                                                                                              1. хорошо оформленный функциональный код может быть не менее удобочитаемым, чем ООП. А плохо оформленный ООП код может быть точно таким же нечитаемым, как плохой функциональный. Пример:
                                                                                                                              можно написать некоторую систему на ООП. Допустим у нас есть класс для обработки и вывода информации о людях.
                                                                                                                              ООП: $man->getHTML();
                                                                                                                              функциональный код: manGetHTML или getHTMLForMan() или как угодно иначе обзовите функцию. Разница - в отсутствии символа ->, но его и заменить можно чем-то если вам удобнее с разделителями.

                                                                                                                              На уровне машины:
                                                                                                                              функциональное программирование: найдем адрес функции, запомним место, на котором выполняется вызов функции, перейдем по адресу функции, выполним ее код, вернем результат куда нужно и продолжим выполнение программы.
                                                                                                                              ООП: обработаем класс и запишем его в память, создадим объект класса и запишем в память, при вызове метода объекта найдем адрес объекта, запомним откуда мы уходим в класс, найдем в классе адрес функции.....
                                                                                                                                0
                                                                                                                                Пример не катит. ООП это не занос набора функций в класс.
                                                                                                                                  0
                                                                                                                                  в вебе так часто получается, особенно если работа идет над какой-то CMS средней сложности... хотя возможно пример действительно не очень вышел. Но, я надеюсь, идея понятна
                                                                                                                                    0
                                                                                                                                    кстати говоря, в данном примере вообще пофигу использовали ли мы классы только как контейнеры для функций или использовали больше возможностей. одна строка, которая вполне может находится внутри метода класса, который выполняет действия над самим объектом этого класса.
                                                                                                                                    Это попытка показать, что нет каких-то особенных различий в удобочитаемости ООП кода и неООП кода. Плюс, что делает машина при том или ином подходе.
                                                                                                                                      0
                                                                                                                                      Если рассматривать с этой стороны то полностью солидарен. Только плз не надо говорить о скорости работы если бы в контексте пхп4 бы принял этот аргумент то в пхп5 это будет экономия на спичках.
                                                                                                                                      Проблема в том что очень мало видел грамотно спроектированных приложений написанных в функциональном стиле. Читабельный, да это часто. Но если говорить о модификации и росте то тут по сравнению с ООП стилем гораздо реже. Кроме друпала ничего даже на ума не приходит.
                                                                                                                                      Подчеркну что я говорю о только своем опыте (4 года).
                                                                                                                                        0
                                                                                                                                        Экономия на спичках - вопрос спорный. В ряде случаев, в небольших проектах - да. В крупных и сложных - совсем нет.
                                                                                                                                        Если у вас простой корпоративный сайт с небольшим кол-вом функций и небольшой посещаемостью, конечно, такая оптимизация чего-либо значительного не даст.
                                                                                                                                        Но если взять крупный портал или сложную систему (например, очень развитую CRM), то такой подход может в итоге помочь. Пусть не так сильно, как оптимизация запросов к БД, но (я считаю, что оптимизируем не только работу с БД) все же даст прирост производительности.
                                                                                                                                        Как я выше писал, для вызова одного метода грубо говоря совершается в два раза больше операций. Каждая требует времени и памяти. В случае простой системы из двух-трех независимых объектов или с крайне неглубокой иерархией классов и объектов нет смысла заморачиваться на этот счет.
                                                                                                                                        Но крупный портал/CRM может содержать десятки классов, сотни объектов, каждый из которых в свою очередь содержит еще десятки объектов. Представьте, сколько в этом случае переходов с одного адреса памяти на другой потребуется в ряде случаев даже для вызова одного метода. А учитывая, сколько раз происходят подобные вызовы и сколько конструкторов мы запускаем, сколько объектов храним в памяти? Прилично выходит в итоге-то.

                                                                                                                                        Мне как-то повезло сравнить в производительности две CMS средней величины. Одна написана на ООП. Вторая - чисто функциональный подход. Набор функций один в один. Обе системы достаточно качественно написаны. Но разница в производительности в реальных условиях оказалась вполне достаточной, чтобы отказаться от системы с ООП.
                                                                                                                                          0
                                                                                                                                          Насчет роста системы и расширяемости, на мой взгляд это недостаток архитектуры большинства неООП систем - ООП тут не причем. неООП системы разрабатывались по большей части когда-то давно. Затем все ринулись использовать везде где нужно и не нужно ООП. Начали прорабатывать более расширяемые системы, но уже проектировали их с ипользованием ООП. А про функциональный подход все забыли, потому что в нюансах не разбирались, или просто на моду повелись или по каким-либо еще причинам.
                                                                                                                                            +1
                                                                                                                                            >функциональный подход
                                                                                                                                            процедурный. процедурный. процедурный.
                                                                                                                                      0
                                                                                                                                      поддержку полиформизма и инкапсуляцию тоже функциями сможете набросать ? :)
                                                                                                                                        0
                                                                                                                                        для подавляющего большинства операций, производимых CMS и аналогичными web-based системами, она не нужна. а вот когда нужно, тогда да - ООП.
                                                                                                                                        Я ж не сказал, что вообще никогда не нужно его использовать. В большинстве случаев можно и нужно обойтись без него.
                                                                                                                                          0
                                                                                                                                          Как раз для подавляющего большинства таких систем, что бы облегчить себе страдания, и вообще получить кайф от работы полиформизм использовать стоит. Хотя, наверное некоторые любят полчать кайф от написания однотипного кода, который различаеца 2-3 строчками
                                                                                                                                            0
                                                                                                                                            сколько CMS написал, со сколькими сталкивался... увы, полиморфизма там кот наплакал, да и не особо было куда его приткнуть...
                                                                                                                                            Если мы делаем мегонавороченную CRM, тогда в нем вполне может быть смысл. Если мы делаем среднюю CMS, то вряд ли он где-то нужен.
                                                                                                                                          0
                                                                                                                                          А почему я такого мнения, я писал выше и описывал процесс с точки машинных операций плюс еще пара слов о синтаксисе и удобству.
                                                                                                                                        +1
                                                                                                                                        А с каких это пор ооп код намного читаем ? да еще написаного разными людьми.
                                                                                                                                        Вообще-то что ооп, что функции написанные разными людьми,
                                                                                                                                        без соблюдения общих правил все равно приведет к нечитаемости кода.
                                                                                                                                        И это факт.
                                                                                                                                        А если один человек будет писать, или группа людей, которые соблюдают единые (внутри конкретно взятого проекта) правила, то все будет читаемо. И не важно, ооп это или функции. Я видел проекты, написаные без ооп и очень легко читаемые. Даже лучше чем некоторые написанные на ооп.
                                                                                                                                        Почему-то ооп код считают более читаеым.
                                                                                                                                        Не в ооп дело, а в программисте, который пишет код.
                                                                                                                                        Если руки из одного места ростут, то ооп подходт не поможет.
                                                                                                                                        написания кода
                                                                                                                                          0
                                                                                                                                          Есть такое мнение: "На ООП проще написать плохой код, но потенциальные возможности также выше."
                                                                                                                                          А еще такое: "Зависит от стиля мышления".
                                                                                                                                          Спор, получившийся ниже, довольно бессмысленен. Хоть бы одну ссылку на исследование дали.
                                                                                                                                        0
                                                                                                                                        1. "узкое место _всегда_ - БД." - Если руки из ЖОПЫ , то ДА оно.
                                                                                                                                        А если нет, то какое? Расскажите, пожалуйста, какое место самое узкое, если руки не из жопы. И не надо мне говорить, что если руки не из жопы, то и узких мест нет.

                                                                                                                                        3. ООП - едиственный правельный метод написания
                                                                                                                                        Поверьте, как человек, руководивший проектом на 40K строк, сделанного по принципу "OOP for the sake of OOP", это очень глупая позиция. ООП в PHP действительно намного медленнее, особенно когда доходит до конструкций типа $this->controller->template->get('foobar', array('a' => $a)); вместо include 'templates/foobar.php'.

                                                                                                                                        4. 5 пункт , я вообще не понял, о чем Афтар говорит(RSS-контроллере Это что за зверь).
                                                                                                                                        Ну если вы не можете, зная что такое RSS и что такое контроллер, догадаться, чем может быть RSS-контроллер (хотя я тоже в первый раз такое слышу), чести это вам не добавляет. Или не знаете?

                                                                                                                                        5. Пункт 8 справедлив лиш в том случае если совокупный доход раза в 4 больше платы за сервак.
                                                                                                                                        Если вы не можете позволить себе виртуальный сервер, возможно, есть смысл подумать о смене профессии.

                                                                                                                                        6. 10 пункт, я уже говорил, у меня на 100 проц. движок динамичный. кеш не нужен, так как у меня нет статичных объектов в принципе(не надо меня шпынять за это, я сам выбрал гибкость в упор статике ).
                                                                                                                                        Ну и дурак. (аче, можно же под конец резюмировать?)
                                                                                                                                          0
                                                                                                                                          А если нет, то какое? Расскажите, пожалуйста, какое место самое узкое, если руки не из жопы. И не надо мне говорить, что если руки не из жопы, то и узких мест нет.
                                                                                                                                          Всё зависит от проекта. У нас узкое место - сетка. Но это потому что мы не используем БД :-)
                                                                                                                                            0
                                                                                                                                            Я понимаю, что узкие места могут быть разными :) просто AlienZzzz, как мне кажется, хотел сказать, что у таких крутых программистов, как он, узких мест не бывает вовсе.

                                                                                                                                            А они всегда есть. Избавился от одного — тормозить будет то, что не тормозило до этого, пока весь процесс тормозило первое )
                                                                                                                                          0
                                                                                                                                          Нащёт ООП поспорил бы. Особенно применительно к web-у. Почти 8-летний опыт разработки под web, сначала на чистом С, потом perl, php а так же управление коллективом разработчиков дает мне уверенность говорить что при числе разработчиков < 10 вполне удается работать используя ТОЛЬКО функциональный подход, используя ООП только для вызова внешних (не самописных) классов.
                                                                                                                                            0
                                                                                                                                            Функциональный подход на нефункциональных языках? Да, это посильнее "Фауста" Гёте. И очень сильно посильнее предложенной кем-то выше эмуляции ООП-а, без использования встроенных в язык ООП средств (вотще какая-то дурная идея).
                                                                                                                                            Однако, вернёмся к функциональному подходу - почему си, перл, пхп, а не... Хм.. А что там у нас есть.. А, вспомнил - видел как-то веб-фреймворк на схеме. Он даже где-то на соурсфорже лежит. Это же жутко неудобно - писать функциональные программы на имеритивном языке.
                                                                                                                                              0
                                                                                                                                              Сорри поторопился - естественно имелся в виду не функциональная а процедурно-ориентированная парадигма в процедурных языках.
                                                                                                                                              p.s. Имеритивных языков не знаю, знаю императивные. Хотя могу и ошибаться, ибо курс лингвистического обеспечения у меня был 11 лет назад.
                                                                                                                                                0
                                                                                                                                                Императивные, конечно. Описка.
                                                                                                                                                Но вы тоже удивили в комментариях выше - вводите жёсткие правила оформления-именования, увольняете за несоблюдение и всё ради чего? Чтобы ваши процедурные программы читались не хуже оо-шных? А смысл? Не проще ли писать оо? Ведь это удобнее. Какие-то религиозные принципы запрещают пользоваться оо? Ну, то есть с сями я понимаю, ситуация может того требовать, но в более других языках... Смысл?
                                                                                                                                                  0
                                                                                                                                                  Смысл - иметь наглядный, хорошо управляемый и поддерживаемый код проекта. В то время, когда проект начинал писаться было принято такое решение - не использовать ООП вообще (кроме вышеоговоренных случаев использования заимствованных библиотек, интерфейс которых предполагает не процедурный а объектный доступ). Этот подход показал свою жизнеспособность. Кроме того я лично не считаю что ООП удобнее во всех ситуациях.
                                                                                                                                                    0
                                                                                                                                                    Выглядит либо как религия, либо как будто принимающий это решение просто не понимал оо парадигму, поэтому решил запретить. :)
                                                                                                                                                    Я понимаю смысл этого в си, как уже говорил. Но в таком уродстве, как пхп писать без оо - ужос, по-моему. То, что так можно делать и это жизнеспособно, это ясно-понятно. Что во всех ситуациях оо не панацея, тоже, но в веб разработке, да на пхп... Выглядит странно. Я даже в крошечных проектах как минимум оо-обёртку вокруг дб приделываю. Экономит ну очень много времени, сил и нервов.
                                                                                                                                                      0
                                                                                                                                                      Хм... А просветите, пожалуста, начинающего, чем именно ООП реально, и дейтсивтельно, лучше процедурного стиля?
                                                                                                                                                      Я, например, выделил пока для себя только один возможный плюс: расширяемость, в случае с Perl — через @ISA;
                                                                                                                                                      Но это частично обходится объявлением функции прямо в namespace целевого package (SomeApp, к примеру) через typeglob'ы и no strict 'refs';. Остается только вопрос, как её Export'ировать в другие модули при use SomeApp.
                                                                                                                                                      Другой вариант - глобально эскпортированный во время use хэш анонимных функций в роли объекта.

                                                                                                                                                      В общем, плюс ООП: расширяемость. Ещё плюсы у ООП есть?
                                                                                                                                                        0
                                                                                                                                                        Конечно есть. Как ни странно, они следуют прямо из определения :)
                                                                                                                                                        +инкапсуляция данных
                                                                                                                                                        +наследование (возможно, именно это вы назвали расширяемостью)
                                                                                                                                                        Конечно, всё "обходится", но ведь это некрасиво, сложно в поддержке и вообще сложно.
                                                                                                                                                          0
                                                                                                                                                          Да, я имел ввиду именно наследование. Тоесть, кроме наследования (которое есть суть расширение методов и/или свойств объекта новыми методами, если не ошибаюсь) и возможности "прятать" переменные (свойства) — больше никаких плюсов?
                                                                                                                                          +3
                                                                                                                                          Докатились, теперь на хабре вешают ссылки как подписи к камментам.
                                                                                                                                            0
                                                                                                                                            пригласите НЛО ;)
                                                                                                                                          –1
                                                                                                                                          Поскольку это не было написано выше, упомяну, что для кэширования в больших проектов удобно использовать memcached.
                                                                                                                                          И не только для кэширования, но и как хранилище данных, которые не жалко потерять при перезагрузке.
                                                                                                                                          • UFO just landed and posted this here
                                                                                                                                              0
                                                                                                                                              Честно говоря меня, достали уже высказывания "используйте memcached". Вы понимаете, что говорите? memcached это только один из способов хранить кэш, а не какой-то магический подход, который сделает все сам. Вы fullpage-кэш там храните?
                                                                                                                                              • UFO just landed and posted this here
                                                                                                                                                  0
                                                                                                                                                  Согласен. Плюсов у него много:
                                                                                                                                                  - потоковая безопасность инкремента/декремента
                                                                                                                                                  - соединение через сокеты (это же и самый большой минус)
                                                                                                                                                  - встроенный хендлер для сессий
                                                                                                                                                  - и еще несколько :)
                                                                                                                                                  Просто большинство даже не пытаются искать другие решения. А насчет fullpage я не случайно, я такой проект видел.
                                                                                                                                                  Другой случай - на каждом сервере стоит memcached и на нем храняться данные, специфичные для этого сервера. На вопрос почему не APC, ответили, что такого не знают.
                                                                                                                                                  • UFO just landed and posted this here
                                                                                                                                                  0
                                                                                                                                                  Извините, наболело :)
                                                                                                                                                    0
                                                                                                                                                    Разумеется это не серебряная пуля и тем более сам он ничего не делает, но тем кто ещё не знает о таком варианте (но работает над нагруженным проектом работающим на N серверах) нужно как минимум знать о нем.

                                                                                                                                                    1. Мы храним в memcached не готовые страницы (они разные и кэшировать их бессмысленно), а различные данные, которые в маленьких проектах можно на каждый запрос собирать из базы и других источников. Но в больших это становится накладно.
                                                                                                                                                    Разумеется нужно помнить об инвалиданции (или обновлении) кэша при изменении данных, поэтому для ненагруженных проектов это только лишнее усложнение кода.

                                                                                                                                                    2. В memcached хранятся данные которые вообще никогда не пишутся на диск (в базу), например число неудачных попыток ввести пароль для замедления подбора паролей. С учётом того, что некоторые пытаются подбирать пароли со скорость 100 (и больше) запросов в секунду, на sql это создаёт заметную нагрузку. А после перезагрузки мемкешеда подибральщик все равно снова упрётся в лимит и в потере этих счётчиков при перезагрузке memcached ничего страшного нет. Если поискать то в больших проектах таких данных (которые не иногда жалко терять) набирается достаточно, чтобы намmemcached сэкономить несколько SQL-серверов.
                                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                                        0
                                                                                                                                                        Ну я думаю все, кто с нагруженными проектами работает (интересно с какого уровня начинаются "нагруженные") уже давно знают про memcached :)

                                                                                                                                                        2. Насчет подборов - можно это и из кеша убрать, если есть возможность подписывать форму.
                                                                                                                                                    +4
                                                                                                                                                    "адекватного спеца по PHP в Москве - 30-45 тыс. рублей в месяц"
                                                                                                                                                    Я бы сказал 45-75
                                                                                                                                                      0
                                                                                                                                                      смотря какой уровень считать адекватным :)
                                                                                                                                                      0
                                                                                                                                                      наконец-то кто-то высказался по существу! респект чувак.
                                                                                                                                                      плюсанул бы, да кармы нету.
                                                                                                                                                      насчет пхп с акселератором на дев-машине могу поспорить конечно... а могу и не спорить :)
                                                                                                                                                      насчет того что пхп5 нормальный язык.... тоже спорить не буду. :) большую часть недочетов все равно обещаются пофиксить в 6м,а синтаксис... ну, скажем так - дело привычки.
                                                                                                                                                      вообще нету хороших и плохих языков, есть комьюнити. в пхп оно, надо сказать, _в_среднем_ поадекватней чем в ROR'е.
                                                                                                                                                      А вообще надо быть полиглотом. Гетерогенные системы ftw
                                                                                                                                                        0
                                                                                                                                                        6-1 обещает быть более глючным, чем 5-й. Я скептически отношусь к факту его появления.
                                                                                                                                                          +1
                                                                                                                                                          насчет глюков - согласен, до 6.2.0 на шестерку даже смотреть смысла не будет.
                                                                                                                                                          но скажем так. в перспективе - пхп скорее всего станет довольно мощным all-in-one языком.
                                                                                                                                                          на самом он весьма неплох, что на данный момент, что в перспективе. проблема в том, что из него из-за элементарной безграмотности пытаются сделать панацею.
                                                                                                                                                        0
                                                                                                                                                        Про зарплату "адекватного спеца по PHP" откровенно удивили. Я и за 60 найти не могу уже который месяц.

                                                                                                                                                        P.S.: Пользуясь случаем, если кто ищет работу программистом (PHP) - пишите. (-:
                                                                                                                                                          0
                                                                                                                                                          Везучий. У меня 96k никто освоить не годен.
                                                                                                                                                          http://phpclub.ru/talk/showthread.php?s=&threadid=107308&rand=0
                                                                                                                                                            0
                                                                                                                                                            Вот только какие мы с Вами выводы должны сделать? Предлагать по 100-150 т.р.? Но при все желании, таких товарищей единицы. А достаточно приличное количество программистов и 40 не стоит.
                                                                                                                                                              0
                                                                                                                                                              Приличное? А Вы, батенька, оптимист :) Если учесть, что PHP предрасположен к недотепам и "фейс-контроля" у него никакого, то и недотеп, соответственно, очень много, их в десятки раз больше, чем специалистов.

                                                                                                                                                              Специалист, профессионал, стоит дорого, но другие мне просто не нужны. А раз не нужны, я делаю что могу, чтоб он работал не где-либо, а именно у меня.
                                                                                                                                                                0
                                                                                                                                                                Оптимист. Увы.

                                                                                                                                                                Так я к тому и говорю. Я ведь тоже делаю все что я могу, что бы такие люди работали у меня. Конечно, 96 предложить не могу (у меня требования значительно скромнее), но и 60 платить за, извиняюсь, раздолбайство, опоздания, сорванные сроки и трепание нервов как-то не очень хочется. А пока, увы, это суровая действительность.
                                                                                                                                                              0
                                                                                                                                                              можно тест глянуть? интересно ? :)
                                                                                                                                                                0
                                                                                                                                                                А он заранее не планируется, этот тест. Люди разные, уровень владения разными вещами заявляют разный. Вы мне резюме пришлите, в вакансии мыло указано, а я Вам намылю пример теста :) Под Вас.
                                                                                                                                                              0
                                                                                                                                                              даю 30, нужен простой код без фреймворков
                                                                                                                                                                0
                                                                                                                                                                и ваш тест?)
                                                                                                                                                                +3
                                                                                                                                                                PHP — это глобально и надёжно.
                                                                                                                                                                  0
                                                                                                                                                                  Респект. Хоть одно дельное и по сути! Единственное с чем не согласен, это с расценками:) А так, 5 балов!
                                                                                                                                                                    0
                                                                                                                                                                    Во, перечитал... Пунктик 6. Маршрутиризацией занимается на FrontController, а Router и их можно наштамповать ровно столько, сколько нужно.
                                                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                                                        +6
                                                                                                                                                                        Ой ща по шапке (карме) настучат

                                                                                                                                                                        Проблема большинства PHP разработчиков в том, что большенство не разработчики а кодеры, которым только и надо писать, писать и ещё раз писать. Если человек (будущий "developer")начинает учить язык с книги "PHP для чайнегов", а перед этим в техникуме или ПТУ какя то бабушка читала им паскаль и делфи, но у человека ничего толкового из этого не вышло, ИМХО удел такого девелопера получать максимум 1000 уе (предел мечтаний), и писать свой страшный код.
                                                                                                                                                                        Программировать надо начинать с основ теории алгоритмов. Язык программирования это всего лишь инструмент, как было выше подмечено, если человек не может найти правильное (рациональное) решение проблемы, то на каком бы языке он не писал, производительность будет страдать, будь то С++ или bash-скрипт.

                                                                                                                                                                        PS моё ИМХО, не высосано из пальца. Я когдато учился в техникуме радиоэлектроники (сам я на радиотехнику учился), у нас было отделение программирования, так им преподавали языки или студенты вузов, или бабушки которые мне преподавали технологию производства или РЭА. Понятное дело каких программистов выпустил техникум.Те кто хотел научится, учились сами.
                                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                                            +1
                                                                                                                                                                            Всё верно. Никакой кеш не ватыщит из квадратичного алгоритма линейный. Но вот микрооптимизации (двойные кавычки против одинарных, echo против print) - это действительно такие крохи, которые мало когда играют роль ибо цена их - O(1), как ни крути.
                                                                                                                                                                              0
                                                                                                                                                                              Кэш может снизить влияние от разницы между квадратичным и линейным. Другое дело, что сделать проще в данном случае - изменить алгоритм или прикрутить кеш (а его потом еще и поддерживать надо).
                                                                                                                                                                            0
                                                                                                                                                                            Вообщем то нормально написано, люблю импрессивные стили.

                                                                                                                                                                            Но есть откровенный бред насчет оптимизации и держания на дэвэлопмент-тачке акселератора.
                                                                                                                                                                              0
                                                                                                                                                                              Чета стилистика текста здорово смахивает на promp-перевод с инглиша. Обычно тамошние юмористы так тонко шутят "ты отстой, ты неудачник и т.п." "На вас надет... ТАНК" - с этой фразы вообще упал.
                                                                                                                                                                                0
                                                                                                                                                                                Не важно, какой концепт вы применяете - строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле "PHP для чайников" - ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.

                                                                                                                                                                                Мне кажется, парадигмы применяют не столько для роста производительности, сколько для упрощения поддержки продукта в дальнейшем. От статьи остаётся ощущение, что на концепты можно забить, так как роста производительности они не дают. Но неправильно выбранный концепт (или вообще отсутствие концепта) доставят вам в итоге не меньше проблем, чем низкая производительность. С хорошим концептом производительность можно поднять кэшированием и т.д., а вот с недостатками концепта бороться сложнее.
                                                                                                                                                                                  0
                                                                                                                                                                                  Статья не ахти , в основном стеб и мелкие замечание про то что нужно использовать а что нет , такие выпады без цифр и графиков оценки производительности того или иного метода оптимизации не заслуживают внимания , "да и вообще вы все такие неумехи" - это наверное главная мысль этой статьи , автор явно не потрудился написать - "а почему так нужно писать ту или иную конструкцию ?" , наверно лень .

                                                                                                                                                                                  К чему лично я придрался :

                                                                                                                                                                                  1) узкие места в php пропорциональны опытности программиста и только ,
                                                                                                                                                                                  45тыс по москве - бред , эта з.п. не спеца , а извините студента на поддержке и разработке модулей корп. сайта или движка.

                                                                                                                                                                                  2) акселератор - где они и как их зовут?!.

                                                                                                                                                                                  3) Парадигмы применяются исключительно для : быстрой разработки , беспроблемного расширения и
                                                                                                                                                                                  наращивания функциональности.

                                                                                                                                                                                  4) у меня фреймворк написан - обслуживает 300к запросов в день - кеширования нет , весь вопрос в правильной модели самого движка, естественно, для каждой задачи он сугубо индивидуален.

                                                                                                                                                                                  5) экономить на копейках в производительности на print или echo - просто смешно.

                                                                                                                                                                                  7) Это вообще блеск ! Сначала пишут удобный код а уже потом производительный.

                                                                                                                                                                                  13) Не хватает пространства имен :)
                                                                                                                                                                                    0
                                                                                                                                                                                    1) про пропорциональность узких мест непонятно. Поясните, пожалуйста. 45К - нормальная зарплата, и не в Москве. Бывает выше, но чаще - ниже.
                                                                                                                                                                                    2) eAccelerator, xCache, APC,... вопрос "где они?" непонятен
                                                                                                                                                                                    3) да
                                                                                                                                                                                    4) "300К запросов в день" - надеюсь, вы понимаете, что эта цифра вообще ни о чем не говорит (пиковая нагрузка? запросы к чему вообще - к БД, к апачу, к страницам?....)
                                                                                                                                                                                    5) об том и статья ;)
                                                                                                                                                                                    7) производительность - это нефункциональное требование, которого может и не быть. Возможно, о нем вообще не надо думать. В любом случае, об этом надо думать не после написания кода.
                                                                                                                                                                                    13) угу, согласен :)
                                                                                                                                                                                      0
                                                                                                                                                                                      "и не в Москве" → "и даже в Москве"
                                                                                                                                                                                        0
                                                                                                                                                                                        1) спец уже на стадии проектирования знает узкие места , именно там он приложит усилия на оптимизацию.

                                                                                                                                                                                        2) это вопрос автору , статья без ссылок на хоть какое-то решение , для просвещения незнающих - просто болтовня.

                                                                                                                                                                                        4) 300к - это уников в день , остальное можно подсчитать.

                                                                                                                                                                                        5) Про это статья о производительности и как бы :) , узких местах в php.
                                                                                                                                                                                        P.S. могу добавить что для много миллионных загрузок сам php будет узким местом :)
                                                                                                                                                                                        0
                                                                                                                                                                                        3) Вот речь и идет о том, что производительность от парадигмы не зависит.

                                                                                                                                                                                        4) 300к запросов в день это всего лишь 3.5 запроса в секунду ) не такая большая цифра, чтобы по ней судить о производительности.

                                                                                                                                                                                        7) Не понял, вы согласны или несогласны с "Сначала пишут удобный код а уже потом производительный."? :)

                                                                                                                                                                                        13) В 5.3, кстати, будут.
                                                                                                                                                                                          0
                                                                                                                                                                                          300к запросов в день это не всего лишь 3.5 запроса в секунду. Это где-то 35 в пике (если только у вас сайт не слишком глобальный, то пик - где-то 10x от среднего). Уже ничего так. Но сможет ли ваш движок обратотать 3M запросов в день (300 запросов в секунду)? Разумный запас прочности движка - 10х от сегодняшних потребностей (если ваша популярность вырастет не в 10, а в 100 раз у вас будут деньги на то, чтобы всё переписать на совсем другой парадигме, а 10-кратный рост может случиться достаточно быстро для того, чтобы у вас не было на это времени).
                                                                                                                                                                                            –1
                                                                                                                                                                                            3)а вот и зависит : всегда гибкость за счет производительности

                                                                                                                                                                                            4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.

                                                                                                                                                                                            7) не согласен , нужно конечно заботится о производительности ка си-программист :) , но не до паранои.Пишут код , тестируют на нагрузках , а потом оптимизируют .
                                                                                                                                                                                              0
                                                                                                                                                                                              >4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.
                                                                                                                                                                                              -
                                                                                                                                                                                              не надо утверждать то, о чем не знаете.
                                                                                                                                                                                                0
                                                                                                                                                                                                Послушайте уважаемый ,
                                                                                                                                                                                                Во-первых : из каких соображений вы сделали вывод что я этого не знаю ?

                                                                                                                                                                                                Во-вторых : в моей практике есть реальный пример новостного портала на bitrix 4 , поверьте он и на 50к загибался :).

                                                                                                                                                                                                И в-третьих : я говорил про чистую работу bitrix, без сторонних серверных или софтверных решений , типа memcachd , gnix.
                                                                                                                                                                                                  0
                                                                                                                                                                                                  1. из вашего утверждения, на которое я собственно и ответил

                                                                                                                                                                                                  2. вы в этот момент мониторили серверы (апач, mysql, нгинкс), к которым обращался сайт? Лично я мониторил, когда проводил нагрузочное тестирование в 1М на битриксе. Правда, это была не древняя четверка (вы бы еще битрикс3 вспомнили) Еще раз: 50К чего? запросов в секунду? что значит "загибался"? время отклика превышало 2 сек, или 500-я ошибка вылезала?

                                                                                                                                                                                                  3. так может для чистоты эксперимента еще и кэширование в самом битриксе отключить, и все это на Р-MMX поставить под виндой?
                                                                                                                                                                                                    0
                                                                                                                                                                                                    но вообще я согласен, битрикс - тормоз тот еще :) без костылей хрен заставишь двигаться
                                                                                                                                                                                              0
                                                                                                                                                                                              По поводу 4 - вопрос скорее, состоит в том, сколько вы времени потратили на поддержку 300к на уровне PHP и сколько бы вы потратили, применив кэширование.
                                                                                                                                                                                              0
                                                                                                                                                                                              Наконец-то хоть кто-то написал по сути, а то куча народу уже написало статьи на тему вызова echo, но нигде не было приведено, сколько в секундах это экономит времени.
                                                                                                                                                                                                0
                                                                                                                                                                                                Так устройте benchmark.
                                                                                                                                                                                                  0
                                                                                                                                                                                                  Так я-то как раз не сторонник мелочевки, потому и доказавать нет смысла :)
                                                                                                                                                                                                0
                                                                                                                                                                                                Вы всё еще пытаетесь кому-то доказать что он не удачник? Вы неудачник!
                                                                                                                                                                                                  0
                                                                                                                                                                                                  Молодца ))))
                                                                                                                                                                                                    0
                                                                                                                                                                                                    Я бы просто запульнул в афтора помидором , на большее он не тянет.
                                                                                                                                                                                                      0
                                                                                                                                                                                                      убейте себя ап стену
                                                                                                                                                                                                        0
                                                                                                                                                                                                        А мы поможем взять для этого разгон используя магическими пенделями.