Почему бы не использовать агентов jmeter, если вы проседаете по CPU на одном инстансе jmeter.
Они вполне хорошо справляются с задачей создания распределенной нагрузки с разных узлов.
1) спец уже на стадии проектирования знает узкие места , именно там он приложит усилия на оптимизацию.
2) это вопрос автору , статья без ссылок на хоть какое-то решение , для просвещения незнающих - просто болтовня.
4) 300к - это уников в день , остальное можно подсчитать.
5) Про это статья о производительности и как бы :) , узких местах в php.
P.S. могу добавить что для много миллионных загрузок сам php будет узким местом :)
3)а вот и зависит : всегда гибкость за счет производительности
4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.
7) не согласен , нужно конечно заботится о производительности ка си-программист :) , но не до паранои.Пишут код , тестируют на нагрузках , а потом оптимизируют .
Статья не ахти , в основном стеб и мелкие замечание про то что нужно использовать а что нет , такие выпады без цифр и графиков оценки производительности того или иного метода оптимизации не заслуживают внимания , "да и вообще вы все такие неумехи" - это наверное главная мысль этой статьи , автор явно не потрудился написать - "а почему так нужно писать ту или иную конструкцию ?" , наверно лень .
К чему лично я придрался :
1) узкие места в php пропорциональны опытности программиста и только ,
45тыс по москве - бред , эта з.п. не спеца , а извините студента на поддержке и разработке модулей корп. сайта или движка.
2) акселератор - где они и как их зовут?!.
3) Парадигмы применяются исключительно для : быстрой разработки , беспроблемного расширения и
наращивания функциональности.
4) у меня фреймворк написан - обслуживает 300к запросов в день - кеширования нет , весь вопрос в правильной модели самого движка, естественно, для каждой задачи он сугубо индивидуален.
5) экономить на копейках в производительности на print или echo - просто смешно.
7) Это вообще блеск ! Сначала пишут удобный код а уже потом производительный.
Они вполне хорошо справляются с задачей создания распределенной нагрузки с разных узлов.
2) это вопрос автору , статья без ссылок на хоть какое-то решение , для просвещения незнающих - просто болтовня.
4) 300к - это уников в день , остальное можно подсчитать.
5) Про это статья о производительности и как бы :) , узких местах в php.
P.S. могу добавить что для много миллионных загрузок сам php будет узким местом :)
Во-первых : из каких соображений вы сделали вывод что я этого не знаю ?
Во-вторых : в моей практике есть реальный пример новостного портала на bitrix 4 , поверьте он и на 50к загибался :).
И в-третьих : я говорил про чистую работу bitrix, без сторонних серверных или софтверных решений , типа memcachd , gnix.
4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.
7) не согласен , нужно конечно заботится о производительности ка си-программист :) , но не до паранои.Пишут код , тестируют на нагрузках , а потом оптимизируют .
К чему лично я придрался :
1) узкие места в php пропорциональны опытности программиста и только ,
45тыс по москве - бред , эта з.п. не спеца , а извините студента на поддержке и разработке модулей корп. сайта или движка.
2) акселератор - где они и как их зовут?!.
3) Парадигмы применяются исключительно для : быстрой разработки , беспроблемного расширения и
наращивания функциональности.
4) у меня фреймворк написан - обслуживает 300к запросов в день - кеширования нет , весь вопрос в правильной модели самого движка, естественно, для каждой задачи он сугубо индивидуален.
5) экономить на копейках в производительности на print или echo - просто смешно.
7) Это вообще блеск ! Сначала пишут удобный код а уже потом производительный.
13) Не хватает пространства имен :)