Артём: Ну так оптимизируте. Самые простые варианты я вам описал. Зпускаете скрипт под профлировщиком. Смотрите, где он тратит больше всего времени и думате, как можно оптимизировать этот кусок кода. И так по кругу, пока не добьетесь удовлетворительных результатов.
В подавляющем большинстве случаем узкое место - это работа с сетьи и базой данных. Сократите количество обращений к бд до минимума (кеширование, отдоженая запись, оптимизация запросов) и получите большой прирост в скорости.
Артём: php.net/manual/en/book.opcache.php Это расширение кеширует байткод вашего приложения и при повтороном запуске интерпретация не требуется. Начиная с верчии 5.5 поставляется по умолчанию.
Если крон и скрипт выполняются на одном сервер попробуйте запускать напрямую, а не через сеть, тогда можно будет вообще отказаться от nginx.
Therapyx: На то, что вы написали достаточно пары лет, а не 30. Не надо сгущать краски. Конечно же я говорю о паре лет нормальной работы, а не тупого составления типовых(!) запросов.
По поводу прототипа вы несомнено правы. По поводу "ведет себя под нагрузкой", стоит учитывать, что это не SAAS платформа, а скорее коробочное решение. Мне надо - я запустил у себя на сервере, мы командой пользуемся. Кому то надо - развернули у себя. Получается, что нагрузка будет не такой большой.
Super User: Кто такой Страуструп я знаю. И приведение его цитаты было бесполезно.
Надо выбирать не максимально подходящий, а оптимально. Работая над проектом в свободное от работ время, очень важно чтобы это приносило удовольствие. Я не просто так обратил внимание, на то, что это не комерческая разработка, а личный проект.
К тому же ноду нельзя назвать максимально подходящей. Тот же экланг и акка умеют то же самое, только через акторы, что удобней на мой взгляд, плюс многопоточность. Если бы ответ был однозначным, я бы не спрашивал.
И что? Про go, я написал лишь то, что я с ним не работал. Ноду я ни в коем случае не ругал, а сказал, что мне лично она не нравится. В общем ваш коммент не сильно полезен для решения вопроса.
С асинхронностью как раз все впорядке. Я заюзал icecoffeescript и с колбеками вообще все хорошо стало. Тут неприязнь чисто личная. Мне не нравится его система типов (частично помогает typescript), отсутсвие многопоточности, его модель ООП. Не очень хочется писать на языке, который лично мне отвратителен.
Хм. Занимательная штука. Не знал (точнее не задумывался) что для сокет соединений можно отдельную прослойку поставить на сервер. Спасибо.
Проект на стадии проектирования. Есть тз, схемы, прототипы интерфейса, описаны сценарии. К кодингу как раз только приступаю. Подбираю язык под задачу. Хоститься буду на гитхабе. Если хотите кину сюда ссылку, как начнется работа.
sim3x: Изначально хеш был просто случайной строкой. Но в данном решенее это просто число, которое при необходимости можно добить нулями слева до нужной длинны.
Это костыль, а не решение. Так как не решает поставленую задачу в полной мере. Обеспечивает уникальность, но СУРБД не страхует от ошибки в случае прямой модификации.
Павел Кузьмин: Ну, я с ним ознакомился довольно поверхностно. Но сразу резануло глаза отсутствие нормлаьного автодополнения в IDE. Нашел в интернете специальный файл, который давал ide нужные данные и автокомплит в общем то работал. Но я считаю, что это не нормально.
И на сколько я помню фасады у них в глобальной области видимости лежат.
Павел Кузьмин: Если смотреть в общем, все вреймворки одинаковы. Они дают кеш, orm, роутинг, mvc, хелперы разныеб IoC и т.п. Как раз каркас общей логики работы приложения. Так же все они дают возможность делить код на изолированные части (модули, бандлы и т.д.) и реюзать их в смоих приложениях. Я писал и на yii (и первый и второй) и на симфонии 2.6. Так же поковырял ларавел 5.
Ларавел вызвал отвращение, а вот Симфония мне понравилась. Там действительно все правильно и четко сделано. Особенно мне понравились анотации, которым там отдается предпочтение.
Но yii проще. И порог вхождения ниже и меньше ограничений накладывает. Я, конечно, люблю правильную и красивую архитектуру, чтобы кругом абстракции. Но это мешает работе. Слишком много внимания требует.
Есть распространенное мнение, что симфония подходит для больших и долгоиграющих проектов, а yii для небольших. Так вот все это глупости. Я лично участвовал в нескольких проектах на yii, которые живут уже больше 4 лет. Если сделать общение между модулями через события, то все замечательно работает и сопровождается.
Так же часто можно услышать довод, что в yii есть божетсвенный объект \Yii::$app, который связывает все приложение. Но это просто точка доступа к фабрикам. По сути \Yii::$app->getCache(), getDb() и т.п. это все IoC контейнеры. Просто в отличае от симфонии к ним можно обратиться через единую точку доступа, а не создавать экземпляры.
Я на yii пишу с самой беты первой версии и мне очень нравится этот фреймворк. Не без косяков конечно, особенно в первой версии были, но где их нет? Зато мне фреймворк помогает, и мне всего один раз пришлось с ним бороться.
Павел Кузьмин: То, чем вы собираетесь заниматься и есть изобретение велосипеда. Возьмите за основу тот же yii. И пишите для него модули: гелерею, контакты, новости. Сам фреймворк будет исполнять роль ядра. Создали проект. Скопировали туда нужные модули, прописали из в конфиге и готово.
daMage: По уму надо этот класс импортировать (use \Models\Image), и указывать короткое имя.
Тестировать будет сложнее, если ваш код будет зависеть от изменяемого окружения. А константы как раз неизменяемы. Так что на тестирование они никак не повлияют.
Дмитрий Логвиненко: Джуниор - это программист, который способен сам решать поставленые задачи, хоть и не оптимальным способом. Ну и сложную архитектуру спроектировать врядли сможет.
Важно опнимать, что джуниор - это не полный ноль. До него еще тоже надо дорасти.
Вот такой же вопрос на стеке, где все подробно объяснено: stackoverflow.com/questions/26763298/how-do-i-work...