Погодите-погодите. Давайте разберемся с терминологией и смыслом.
Напомню, что разговор идет об этой вот интересной фразе:
Гигабит легитимного хттп траффика свалит что угодно
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
К тому же 10 гигабит http запросов и 10 гигабит http закачек несколько разные вещи, согласитесь.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
GET /testFile.pngi HTTP/1.0
Host: test.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://habrahabr.ru/
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
У меня работающий клиент, который выдерживал более 70000 одновременных запросов на Zend
70 тысяч запросов на Zend это что значит? 70k req/sec? 70k req/day?
Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.
60 запросов в секунду это не DDOS :)
к скрипту с 12 запросами к БД.
Сколько миллионов записей на таблицу, какой характер запросов — write/read? Какая репликация / может у вас шардинг?
Более чем уверен, тот же сайт но на Zend уже давно бы валялся.
Вы зря так уверены :) Вопрос ведь не в интерпритаторе php. Ну включили APC, не гоняет теперь байткод каждый раз. А вот к БД нужно открыть коннект, закрыть коннект, прочитать что-то, записать что-то.
Я не к тому, что фреймворк — «плохо, плохо, руки прочь», я к тому, что вы как-то уж больно много нагрузки вкладываете в роутинг и десяток классов фреймворка. Что ZF, что yii.
Функция main для нас неизбежное наследие С и избавиться от нее без лишних проблем тяжело. — очень интересно, как бы вы от нее избавились.
Прочитать описание таких вещей, как Паттерны.- если для новичков, то зачем им паттерны. У нас был один начитавшийся, который пытался их суньть везде, где нужно и не нужно.
Советую автору почитать мнения Дейкстры о ООП.
Все задачи в заданные сроки пишутся — вы Blizzard об этом скажите.
ок я только за, как вы предлагаете решить с циклом ведь данные дергаются внутри foreach() Перенести цикл целиком в контроллер или как? Буду благодарен за дельные рекомендации.
Например так, так или вот даже так.
Каждый раз когда программист вручную экранирует в шаблоне какие-то данные умирает котенок. Потому что забыть забываются и пропускаются такие штуки на-раз.
Ситуация, когда вьюха получила уже экранированные данные тоже нередка.
Смысл в том, чтобы в шаблоне вызывать формирование правильного формата даты, обрезать данные из модели?
Зачем это делать, если формированием даты занимается более высокоуровневый обьект — модель, которой помогают настройки интернационализации? А если time_ago для post нужно будет рисовать в одном формате, а для entity2 в другом? Copy/paste.
Экранирование и фильтрация это тоже задача контроллера. Вьюха должна получать уже готовые данные.
Не похоже на best-practice, И их в вас Fuel не вдолбил. Он и не смог бы, потому что framework лишь кодобаза, реализующая типовые функции. А вы тут превозносите его :)
Фреймворк и правда имеет место быть. Другой вопрос, что статья ни о чем.
The framework was started in late 2010 by Dan Horrigan then shortly after the team grew to include Phil Sturgeon, Jelmer Schreuder and Harro Verton. The team has decades of PHP experience between them and have all been involved with Open-Source projects such as CodeIgniter, PyroCMS, ExiteCMS and DataMapper ORM to name but a few.
Делаешь раз и решение никуда не пропадает — это действительно потрясающе.
Открыли для себя слово «компонент»?
Большое преимущество пакетов в том, что вы можете реюзать логику везде, в шаблоне, в контроллере, в модуле
Что есть для вас «логика»?
я мало использую unit тестирование, oil console, разделение разработки на dev и production, oil migration и многое другое. Но я знаю одно — когда они мне понадобятся, то я с легкостью начну их применять, так как в Fuelphp нет ничего сложного
Код который не писался с расчетом на возможность юнит/функционального-тестирования как правилило тяжко тестируем. Тот же TDD переключает голову в немного другое состояние.
В любом случае это никакого отношения к фреймворку не имеет.
— Получилась гибкое приложение, где почти вся мало мальски реюзабельная логика перенесена в отдельные пакеты с целью реюзать её в следующих проектах. Пакеты это нечто постоянное и переносимое из проекта в проект. Делаешь раз и решение никуда не пропадает — это действительно потрясающе.
— Сами контроллеры лишь выполняют проверки и направляют действия.
— Большое преимущество пакетов в том, что вы можете реюзать логику везде, в шаблоне, в контроллере, в модуле.
— За все время использования фримворка обновлял ядро несколько раз — обратная совместимость не ломалась, обновление сводилось к копипасту с заменой папки core.
— Fuel на столько прост на сколько того хочешь, например я мало использую unit тестирование, oil console, разделение разработки на dev и production, oil migration и многое другое. Но я знаю одно — когда они мне понадобятся, то я с легкостью начну их применять, так как в Fuelphp нет ничего сложного.
Не могу воспринимать это серьезно. Первый и последние пункты это адов треш и угар.
Напомню, что разговор идет об этой вот интересной фразе:
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
10 Гигабит в пике вчера, что я делаю не так? :)
70 тысяч запросов на Zend это что значит? 70k req/sec? 70k req/day?
60 запросов в секунду это не DDOS :)
Сколько миллионов записей на таблицу, какой характер запросов — write/read? Какая репликация / может у вас шардинг?
Вы зря так уверены :) Вопрос ведь не в интерпритаторе php. Ну включили APC, не гоняет теперь байткод каждый раз. А вот к БД нужно открыть коннект, закрыть коннект, прочитать что-то, записать что-то.
Я не к тому, что фреймворк — «плохо, плохо, руки прочь», я к тому, что вы как-то уж больно много нагрузки вкладываете в роутинг и десяток классов фреймворка. Что ZF, что yii.
Врете вы всё. Вы реально упирались в производительность php в ваших веб-приложениях?
Напротив, меня весьма печалит состояние хабов cpp/php/mysql в последнее время.
Прочитать описание таких вещей, как Паттерны.- если для новичков, то зачем им паттерны. У нас был один начитавшийся, который пытался их суньть везде, где нужно и не нужно.
Советую автору почитать мнения Дейкстры о ООП.
Все задачи в заданные сроки пишутся — вы Blizzard об этом скажите.
Например так, так или вот даже так.
Каждый раз когда программист вручную экранирует в шаблоне какие-то данные умирает котенок. Потому что забыть забываются и пропускаются такие штуки на-раз.
Ситуация, когда вьюха получила уже экранированные данные тоже нередка.
Зачем это делать, если формированием даты занимается более высокоуровневый обьект — модель, которой помогают настройки интернационализации? А если time_ago для post нужно будет рисовать в одном формате, а для entity2 в другом? Copy/paste.
Экранирование и фильтрация это тоже задача контроллера. Вьюха должна получать уже готовые данные.
Не похоже на best-practice, И их в вас Fuel не вдолбил. Он и не смог бы, потому что framework лишь кодобаза, реализующая типовые функции. А вы тут превозносите его :)
ps:
если уж используете шорттеги, то проще так:
Официальный сайт
Открыли для себя слово «компонент»?
Что есть для вас «логика»?
Код который не писался с расчетом на возможность юнит/функционального-тестирования как правилило тяжко тестируем. Тот же TDD переключает голову в немного другое состояние.
В любом случае это никакого отношения к фреймворку не имеет.
Зря я вестимо распинаюсь.
Не могу воспринимать это серьезно. Первый и последние пункты это адов треш и угар.
Вот когда отформатированный запрос занимает 36 строчек, это буйство :) И тут ORM скорее в тягость.