как-как... вот так: $memcached->set("password")о, прикольно. Во первых будет $memcached->set("password",'12345678'), а во вторых значит в коде где-то всё-таки будет '12345678', что возвращает нас к начальной проблеме - для того чтобы засетить мемкеш нужно иметь где-то в доступном для кода месте данные. Ой, подождите... это же то от чего вы пытались избавиться?
вместо "12345678" я буду делать $memcached->get("password")Занятно... а как (и главное откуда) в memcached будет попадать password?
Что у вас там за требования,
Minecraft Bedrock ServerЭто не требования, это софт, у которого есть требования. Вот их можно привести, и возможно вам что-то посоветуют. Хотя не очень понимаю почему бы сразу не озвучить проблему в ключе "где найти сервера с конфигурацией ... на европейских площадках". Понимаю, что в России, как в лидере производства серверов и процессоров, наиболее выгодные условия, но возможно что и другие страны что-то смогут предложить...
Уточните, пожалуйста, почему связь через спровочную таблицу будет лучше? Ведь все равно будет WHERE city='1',
Или плюсом будет связывание таблиц через отношения?Это и есть связывание через отношение, вопрос только в том какая форма отношений будет, один ко многим или многие ко многим. По сути 3 нормальная форма требует отделения сущностей в отдельные таблицы и связки через отношения.
Я не знаю, как для апдейт делать пакетную обработку.Никак, апдейт предполагает масс изменения только полей с общим признаком одним набором значений. Через case можно задать несколько значений для соответствующих айди, но это скорее костыль или решение для небольших вариаций значений полей, для большой выборки это неэффективно. Я бы не стал заморачиваться и с инсертами, так как проблема явно не в них. Для начала сделайте чтобы существующие действия работали, так же, как я и писал в собственно ответе, стоит для начала определить где тормоза, а то все ваши действия напоминают купание в зеленке при царапине на пальце...
промежуточные результаты по прежнему через апи?Зависит что вы делаете, и я не вижу где вы там апи используете? Вы просто берете контакты из ранее полученного массива, к апи вы обращались 1 раз, при получении записей, далее вся работа с этим массивом идет... По сути тут у вас та же логика, либо выбирать массово, либо использовать как у вас firstOrNew(), опять же, супервыйгрыша по времени вы не получите, просто оптимальнее выбирать 1 запросом много записей, нежели много раз по 1, так как накладные затраты на каждый запрос сильно выше чем разница между выборкой одного значения и допустим 100 (а при firstOrNew каждый раз идет запрос в бд). Это не критично на 100-300 записей, но не когда у вас их под пару сотен тысяч. Кстати, логичный вопрос - а сколько записей-то в таблицах? И сколько примерно в црм?
Вопрос в том , что неизвестно,какие записи существуют ,а какие не существуют,поэтому нужно апи. В который раз убеждаюсь, что без апи тут не обойтись.Еще раз по шагам:
for ($i = 1; $i <= 100; ++$i) {
$entity = TestLead::firstOrNew(['crmCompanyID'=>$companyID,'TestID' => $row->getId()]);вот как раз для четкого разделения нормальной рабочей системы и "пошпилить" дуалбут очень хорошо подходит.Когда я был помоложе я так и делал, у меня была сусе основной системой и винда для квэйк3. Со временем удобства винды по сути убили весь профит от использования линухов, где-то начиная с ХР... Все работало достаточно совместимо с любой хостинговой платформой. А специфика работы позволяет мне "переключаться" между игрой и работой в произвольное время (что не мешает выполнять работу )). Потом уже стала модной виртуализация рабочего пространства, но у меня по сути 99% проектов ее не требовали. Теперь мне тупо лень переучиваться на линуксовые инструменты, которые у меня есть под виндой. А на поддержке проект доставшийся от фаната докера, причем чел явно ни в кодинге ни в девопс не блистал. Теперь надо поднять и работать с десятком контейнеров, необходимость которых равна абсолютному нулю, часть снести, часть настроить, а часть кода переписать. Ну и напилить кучу новых фич. Как минимум на старте нужен докер локально, все остальные размышления о вреде игр и пользе линукса для печени я буду обдумывать после решения этой задачи )
помучавшись с тормозами будет логично выкинуть windows и идти в мир linuxНу, не у всех жисть заканчивается на использовании докера, я вот пошпилить после работы люблю, инструменты для всяких моих хобби привычные и толковые под вынь, попытка пересесть на линь полностью провалилась. При том что я неплохо знаю ос на уровне администрирования, вплоть до поддержки нескольких локалок в свое время, с маршрутизацией и файерволами, объединением и сепарацией нескольких интернет каналов и прочая... Но как личная домашняя ос не прижилась.
и есть полноценная Ubuntu внутри WSLДа, я в курсе, вопрос был про производительность и возможность запуска в ней нативного линуксового докера с сопоставимой производительностью.
И она работает так же хорошо, как и отдельно стоящая ОС, а также решает проблемы с тормозами docker в Windows.это уже внушает оптимизм! Именно то что я хотел узнать. Спасибо, все таки буду пробовать.
Есть же виртуальные машины для этих задач.Проц амд райзен3 не поддерживает хиперХ, соответственно все виртуалбоксы и прочие средства виртуализации мимо, бо тормозят безбожно, собсно нужен только докер, который вообще пипец тормозит (ну и смысл пихать докер внутрь виртуалбокса отсутствует). Тем не менее, на лине все ходит вполне достойно под докером. Отсюда и вопрос.
В любом случае будет хуже, чем отдельно стоящая как минимум из-за того что ресурсы делятся.Это очевидно. Вопрос только в том будет ли это СИЛЬНО хуже чем отдельная линь. Так то докер в винде и докер в лине по производительности раз в 10 отличаются (естественно в пользу линь).
специальный драйвер, который позволяет внутри wsl использовать видеокарту без проброса pcieЕМНИП бОльшая часть проблем производительности докера завязана на ФС, которая останется(?) виндовой?