link_vrb, откуда пароль возьмется? Где-то будет лежать в открытом виде? Но даже если нет, аргументы команды никогда не являлись безопасными, они могут логироваться, сохраняться в истории, а иногда вообще доступны любому мимо проходящему.
mayton2019, не совсем так, бывает даже от обычных пользователей далеких от серверов и протоколов, слышу, что они покупают белый ip. А значит даже всех костылей не достаточно.
Но тут уж, что имеем, то имеем.
res2001, ресурс IPv4 давно исчерпан. Он все еще живет за счет костылей, потому что фактически адресация поисходит не через него, а с помощью дополнительных механизмов. Большинство машин в интернете по факту не используют IPv4 как интернет протокол, а используют его как протокол локальной сети для подключения к шлюзу, который уже имеет реальный IP и использует его именно как интернет протокол. Когда целый город сидит в интернете под одним адресом, тут явно что-то не то. Вычленение адреса машины не по IP, а по динамическому порту через NAT-таблицы, тоже что-то явно не то. Невозможность подключиться снаружи к такой машине - полное фиаско. А все остальные костыли типа stun лишь подтверждение, что протокол не выполняет своей функции, что как интернет протокол IPv4 давно умер, но его труп дергают за веревочки, делая вид что он жив. Что все к этому идет было понятно даже не в 2000, а уже в 1980-х, поэтому паника обоснованная, но как всегда никто не хочет сделать правильно, если и так деньги платят, поэтому насоздавали костылей и довольны. Сейчас все готово для IPv6, но зачем переходить, если можно барыжить дефицитными IP, и пофиг на то, что IP адреса нужно постоянно переписывать в пакете, что нужно хранить таблицу соответствия портов и адресов, что нужны специальные сервисы типа stun, чтобы заставить работать этот зоопарк.
Adamos, если речь про fixed array, то у него свои ограничения и соответственно не всегда можно лего заменить им стандартный массив. А вот замечание alexalexes про передачу по ссылке, чтобы не копировать весь массив, наверное более часто можно встретить. Опять же, если знать как php работает с памятью и помнить про copy-on-write, то и это не всегда нужно.
По ссылке передается только то, что указано передавать по ссылке, в том числе массивы. Объекты хоть и не создаются заново при передаче в переменную, это не тоже самое, что передача по ссылке, там есть свои нюансы.
И, хотя, я не согласен с Ипатьев по поводу php "запустился, поработал долю секунды, завершился", очень часто работал с демонами, которые работают неограниченно долго. Но, согласен, вопрос "на стеке или в куче" для php не столь актуален. Хотя теоретически вопрос очень интересный, насколько знаю, с 7 версии zval хранятся именно в стеке, но не смогу рассказать подробно как организуется хранение, сам хочу поизучать вопрос.
PHP отработал и забыл, то есть туже работы выполняют при каждом вызове скрипта. В какой то мере это и лучше, память не течет и все сбрасывается при каждом запросе.
совсем не так, когда речь идет о fpm, разве что в cli так, и то, там можно включить кеширование байт-кода.
Нет, видно дело в другом. Если выделить target - nums[i] в отдельную переменную, то производительность будет гораздо выше, чем в рассматриваемом случае. И в байткодах этого не видно.
Скорее всего это связано с оптимизацией хранения переменных с малыми значениями, но наверняка трудно сказать.
Sergey, в оборонке свои требования безопасности, но автор спрашивает не об этом. Поэтому мобильники здесь еще как при чем, для оборонки нормально их вовсе запретить, для коммерческого офиса нет. "ip телефония это не видео-конференц связь", но все это инструменты коммуникации, о чем автор и спрашивает. По безопасности в них нет никакой разницы, разница в том, где стоят серверы и что за ПО используется.
Работал, и опять же это никакого отношения к вопросу не имеет.
Sergey, оборонка это особый вопрос, на режимном объекте вообще мобильные могут изыматься, что вовсе не означает, что нам тоже нужно от них избавляться. Но даже там, нет проблемы использовать что-то подобное зум, с учетом что сервер находится у них и ПО лицензированное. И для видеоконференций они так и делают.
Сергей Малинин, данные не "попадают с одного уровня на другой". Откройте пакет в сниффере, том же Wireshark и посмотрите. В начале пакета будут адреса уровня Ethernet, потому будут адреса TCP/IP, а дальше будут данные HTTP.
Был неудачный опыт работы с ментором и это был большой подводный камень.
Чисто из моего опыта: менторы, коучи и прочие консультанты - они не в команде, а значит не несут ответственности за свои действия, но при этом требуют чтобы выполняли их хотелки.
Я стал на подобную проблему смотреть просто, принимать решения должен тот, кто несет ответственность. Т.к. сторонние не несут ответственности, но могут дать что-то полезное, ответственный должен получить от них четкое понимание, что те или иные внедрения дадут. Понимание должно быть такое, что ответственный сам скажет, да, это правильно, я готов под этим подписаться. В иной ситуации, когда нет понимания, а сторонний расписывает что нужно слепо выполнять инструкции и когда-то (хз когда) наступит светлое будущее, такое слепое следование порождает карго-культ, вроде бы и похоже на что-то рабочее, но по факту абсолютно бесполезное, а из-за временных затрат крайне вредное.
mayton2019, вопрос не столько в том, сколько занимает вся база, а сколько данных активно используется. Если активно используемое помещается в буффер, то не надо ходить на диск за данными и все будет быстро.
Но, в конкретном случае сложно угадать, у автора 100 выборок разных пользователей за одну операцию, что он с ними делает сложно сказать, быть может как раз аналитику и ему нужны все 2 млрд на каждый запрос.
Сергей Кузнецов, ну так, я ж про это и писал.
Что касается rerere, не представляю где это может понадобится. Решать одни и те же конфликты повторно - это какой-то мазохизм, при нормальном git flow такое не нужно.
То, что в where кроме id еще что-то понаписано наводит на странные мысли, либо id не pk, либо ..., но судя по query_time запрос выполняется быстро и все уходит именно на ожидание освобождения лока.