Пул тредов для эмуляции асинхронности - 4. Если вы читаете 5 больших файлов в асинхронном режиме, 5-ый таки подождет до момента, пока не освободится хотя бы один тред. Подобная штука и с драйверами БД: если драйвер реализовывает собственный обработчик очереди + мультитредовость, а данные отадет через event-loop - тогда имеет смысл говорить про асинхронность, в противном случае: 4 потока, ил тюн libuv.
@mr_T
> настройка в конфигурационном файле nginx
ну, такое. он умеет сетапать прямую отдачу страниц, закешированных в кластере мемкешей?))
> авторестарт сервера при ошибках
Авторестарт - это признак очень дурного тона. Если вы сейчас подумали про не перехваченные исключения - да, я именно о них.
> все возможности nginx
Да лааадно.
> быстрое взаимодействие nginx с самим приложением за счет использования сокетов вместо портов
Как правило unix sockets быстрее, но отнюдь не всегда, это базовый функционал вебсервера ноды. https://nodejs.org/api/http.html#http_server_liste...
> приложения на ноде не занимают отдельный порт
это следствие того, что нода будет слушать сокет файл.
Мда... посмотрел интро у этой штуки, полная хрень. Погуглите puppet, chef, salt, vagrant, docker. Окружение - это неотъемлемая часть приложения. Хотите вы того, или нет - ваш код в абстрактном вакууме работать не будет. Да даже сама нода вместе с npm - это тоже часть окружения.
Когда нужна реальная скорость - это не php)). Тот же файлькон такой быстрый потому, что не native php. Еще раз. php - state-less язык, только за счет этого говорить о сверх производительности - это по меньшей мере смешно. На каждый запрос создается отдельный процесс, все окружение поднимается заново.
На счет тестов - это с включенным OPcache? Тот же yii используется через yiilite.php? Что на счет кэширования в memcached?
По хорошему - для тех же статических страниц вполне норм решение - заливать в memcached и читать ngnix-ом на прямую. Для остального - хотите выжать из php максимум:
- отказывайтесь от php в сторону HHVM
- отказывайтесь от серверного рендеринга в пользу SPA, или гибридного (как на пример catberry)
- отказывайтесь от максимального числа запросов к БД, кэшироваться должно практически все
PHP - это язык быстрых решений, но не язык быстрых систем.
@Relike
> будь в курсе событий
Да я в курсе, что 3-ий вышел. Даже в PDO смогли, молодцы, что тут скажешь
> Не переписывать код фреймворка, а расширять его, ведь Yii тоже даёт такую возможность, не так-ли?
Yii-way предполагает, что фреймворк отдельно - ваш код отдельно.
> И я думаю надо придерживаться этого ибо это уже флуд.
На счет ЧПУ: тут все зависит от бизнес задач и прошаренности SEO. Для статей норм решением считается slug названия статьи через дефис + id статьи там же, например:
mysite.com/some-very-cool-article-125
Пример кода, что вы сбросили реально гуано. Дело тут в том, что ваш роутер будет понимать всего один человек в мире. Пример, что написал diamond - вполне ок.
> глобальные переменные... ГДЕ?
конфиги, супер глобальные переменные.
> правила валидации моделей пишутся руками. Ну я думаю другими местами писать не очень удобно.
У того же Yii они пишутся как списки параметризируемых валидаторов, у Doctrine - как аннотации, yaml-ы, или php-шные массивы настроенных валидаторов. "руками" === "свой велосипед"
> что на счет именованных параметров в запросах?
Тут не уточнил, в БД. В оф. справке рекомендуется использовать плейсхолдеры "?", для большого количества плейсхолдеров - это не самая лучшая идея.
При чем тут Yii?)) Это не единственный фреймворк, а первая версия вовнутри - полное гуано. Вторая уже по лучше, но за счет завязки на синглтоне для крупных проектов - не подходит.
Недостатки:
- нет поддержки PSR
- поддержка говна мамонта (5.2.4) ... php 5.3 официально не поддерживается, о чем можно говорить?
- кастомный автолоад, ну это конечно здорово, но уже как бы давно composer придуман и все такое))
- фреймворк как именно часть приложения. Сама идея на момент создания - была вполне торт, но сейчас это не актуально. CI предполагает следующее: если в самом CI что то работает не так, как нужно - правим CI, следственно официальная дока для проекта уже будет не корректной. Пример: у вас есть средний проект на CI, обросший некоторыми изменениями, новый сотрудник работавший с CI раньше должен будет все равно изучить в полной мере, что вы там поменяли, потому как оф. документация уже не будет подходить. Это путь в никуда.
- глобальные переменные...
- правила валидации моделей пишутся руками.
- что на счет именованных параметров в запросах?
- SOA не возможен
Поймите правильно, я тоже когда-то фанател от CI (лет 6-7 назад), но потом познакомился с другими фреймворками и могу сказать следующее: CI любит куча народу потому, что он очень простой, а простой он потому, что предлагает простые решения "в лоб".
В средних и больших проектах решения "в лоб" обычно не приемлемы.
Сергей > но может еще покажет класс в будущем..
Пока не:
- откажется от 5.2
- перейдет на общие стандарты
- откажется от идеологии "фреймворк - можно изменять"
- победит уже существующие микро фреймворки
он так и останется старой какой мамонта.
Relike > С чего ты решил что это прошлое?
Пункты выше
> Он в разы гибче, более расширяемый.
Что на счет silex?
Расширяемость за счет того, что можно поправить код фреймворка - это не расширяемость - пример хреновой архитектуры.
> Возможно я еще не опытен и поэтому мне нравится писать всё самому, но при всём этом создание сайта на CI на много быстрее создания сайта на том-же Yii. habrahabr.ru/post/39300 Когда вырастите с проектов, рассчитанных на одного программиста, это пройдет))
> И сам сайт в разы быстрее работает.
Скорость за счет функциональности - не самая хорошая идея. Если хочешь реальной скорости - смотри в строну Phalcone, или HHVM например.
Ждал уже комментария про пропадание света...
Если вам так нужно качать постоянна - что мешает, например на DO (https://www.digitalocean.com/?refcode=ca94b4fc3b57) поднять vps, + написать скрипт, который будет вам постоянно качать 24/7 с большой скоростью ваши сайты, а дальше их запаковывать. Все что останется - скачать результат
Рекомендую это делать в виртуалке потому как рано, или поздно могут возникнуть конфликты зависимостей пакетов, а на host системе - это не самое приятное.
> Зачем, если это можно реализовать у себя на сервере и не платить. ))
Даже если это домашний сервачок - платить будете (за электричество например).
> Под Linux есть только сторонний консольный клиент.
Чем браузерный вариант не подходит? Вы в вопросе указывете "PHP скрипт" - он в принципе будет работать на вывод либо в веб-сервер -> браузер, либо в консольку.
> Если сервис закроется
Тогда - пичаль. Закроется все рано, или поздно. И ваш скрипт php-шный тоже в один прекрасный момент перестанет работать. Такова жизнь.
> Хотелось бы, все таки, иметь какой-то контроль, что бы данные вдруг не утекли куда-нибудь.
Шифруйте ваши данные AES256, и все норм будет
phpus У вас каша в голове))
SOAP - это протокол
REST - метод взаимодействия систем через HTTP
SOA - сервис-ориентированная архитектура
Микросервисы - довольно новое течение, в отличии от SOA предполагает полную независимость каждой из подсистем на отдельных тазиках.
tugo
> А почему такие ограничения?
>> Просто можно ведь просто писать всё на С++ или нет?
Автор судя по формулировке не имеет представления зачем это нужно в принципе. По этому такие ограничения.
> Почему Qt не взять?
Не суть, можно GTK, можно на чистом OpenGL, можно что угодно))
www.kennynet.co.uk/2014/07/07/nodejs-and-blocked-io
www.future-processing.pl/blog/on-problems-with-thr...
Пул тредов для эмуляции асинхронности - 4. Если вы читаете 5 больших файлов в асинхронном режиме, 5-ый таки подождет до момента, пока не освободится хотя бы один тред. Подобная штука и с драйверами БД: если драйвер реализовывает собственный обработчик очереди + мультитредовость, а данные отадет через event-loop - тогда имеет смысл говорить про асинхронность, в противном случае: 4 потока, ил тюн libuv.
@mr_T
> настройка в конфигурационном файле nginx
ну, такое. он умеет сетапать прямую отдачу страниц, закешированных в кластере мемкешей?))
> авторестарт сервера при ошибках
Авторестарт - это признак очень дурного тона. Если вы сейчас подумали про не перехваченные исключения - да, я именно о них.
> все возможности nginx
Да лааадно.
> быстрое взаимодействие nginx с самим приложением за счет использования сокетов вместо портов
Как правило unix sockets быстрее, но отнюдь не всегда, это базовый функционал вебсервера ноды.
https://nodejs.org/api/http.html#http_server_liste...
> приложения на ноде не занимают отдельный порт
это следствие того, что нода будет слушать сокет файл.
Мда... посмотрел интро у этой штуки, полная хрень. Погуглите puppet, chef, salt, vagrant, docker. Окружение - это неотъемлемая часть приложения. Хотите вы того, или нет - ваш код в абстрактном вакууме работать не будет. Да даже сама нода вместе с npm - это тоже часть окружения.