Dark Hole: вполне себе та, тем паче тут семерка. Вообще если нужно решать задачу фоновой обработки, надо посмотреть в сторону очередей и обработчиков (консьюмеров). Для управления обработчиками использовать supervisor или system.d в зависисмости от конкретной версии ОС.
Victor Alekseev что вы к Мише прицепились, у него все правильно написано :)
Не знаю как сейчас, но вообще у пхп 4 исконных режима работы: модуль веб-сервера, cgi, fastcgi и cli. Fpm - это менеджер процессов, который просто позволяет гибко настривать процессы php под количество запросов (а в качестве протокола fastcgi используется).
>>А можете подсказать, что ещё за варианты работы nginx c обработчиками php
Что вы на крон вешаете или из консоли запускаете - то в cli работает. cgi и mod уже почти никто не использует.
sim3x если у вас не супер-пупер хайлоад можете сейвить в табличку и не париться.
Я имел дело с распределенной архитектурой, пиковыми 3*10^4 rps на нелегкие бекенды и это все спокойно работало через очереди с отдачей id через предварительное сохранение в СУБД.
Если речь про что-то еще большее + ограничение по бюджету, то можно как lega написал. Но там параллельно еще куча вопросов возникнет, станет не до этого) В хайлоадах у кого нормальная архитектура и шардирование, тот и молодец.
fens можно так сделать, но зачем? Минусы, навскидку:
а.) Усложняется отладка и поддержка. Если что-то выбирается не так, понять что не так сложнее. Равно как и объяснить суть схемы не-автору решения.
б.) Отказ от джойнов: вы по-сути описали хранимый запрос, "представление". Обычно в РСУБД представления используют чтобы быстро посмотреть нужную инфу в нужном виде. На уровне бизнес логики в yii это решается как раз джойнами, ибо стандартная функциональность. Смысла пилить велосипед я не вижу, имхо.
>>будет вызывать instantiate у главной модели которая будет возвращать по типу конкретный класс а дальше populate запихнет в модель всю строку ну а модель примет только те поля которые ее
Я так понял вы хотите иметь некое представление где будет все обо всем, а при скармливании данных представления какому-то классу этот класс будет решать, какую конкретную модель вернуть. Хоть тресни, я не вижу каких-то супер-преимуществ у этого подхода. Можно так же через UNION объединить инфу из двух табличек и при необходимости подтягивать общее из справочника.
fens ну наследование - термин из ООП, малоприменимо к РБД, ведь наследуются не конкретные реализации, а классы. Ваша табличка entities напоминает справочник, а таблички с подробностями - суть конкретные данные. Вот я бы на вашем месте и использовал их, а если где-то в логике ПО требуется инфа из справочника - подтягивал бы справочник.
Пума Тайланд чет не понял. ТС пишет про 5 мультов юзеров в СУТКИ, вы пишите про нагрузочное тестирование единовременное. По-моему тут сначала надо понять пиковые нагрузки и потом добавить к ним запас процентов двадцать, и от этого отталкиваться, а не от суммы юзеров за сутки.
По поводу слов DevMan - все зависит от того, как вы подключаетесь к интернету.
Если через wifi+собственный компьютер - админ не увидит ничего, пока сами не поставите его сертификаты.
Если через компьютер организации, где у админа админские права и удаленный доступ на вашу машину - админ может все, начиная от установки сертификатов и заканчивая получением скриншотов вашего экрана.
Оптимус Пьян расшифровка происходит на конечных точках, у клиента и у сервера симметричным ключом, о котором они изначально договариваются на этапе рукопожатия.
>>Например клиент прислал данные, мы ему сразу вернули результирующий ид и отпустили lega ну так ничто не мешает сейвить в табличку, а потом дорабатывать обработчиком, как вы написали далее.
>>В итоге что-бы иметь ид не нужно ждать ответа от сервера, когда он закончит.
но так и не будет понятно, сохранился результат или нет. D - durability.
