rPman

Ты неправильно создаешь csv, строки в валидном csv могут содержать \n и разделитель (дублируется), используй штатную функцию fputcsv, записывающую строчку в файл (аналогично читать fgetcsv)

Для json потоково одним проходом не получится, не зная структуры этих json для csv нужно будет два прохода: первый - определяет все возможные колонки (и если надо сохраняет значения), а второй - заполняет массив строки (для передачи fputcsv) пустыми значениями для тех колонок, значения которых отсутствуют. Чтобы порядок был верный первый проход должен сформировать массив - список названий колонок, а второй проход в цикле формирует массив пробегая по этому массиву названий колонок.

p.s. а у тебя в json точно только один уровень? если есть вложенности на это нужно проверку делать и как то реагировать

причем тут значение prim и количество записей?

rowCount() это прямое (низкоуровневее некуда) определение количество записей в результате запроса
Если тебе нужно знать сколько prim имеет значение null, то либо считай их сам по загруженным результатам, либо сделай отдельно запрос select count(*) from anketa where prim is null

режим pm какой в настройках? если не static то количество текущих процессов веб сервера будут зависеть от нагрузки, полагаю которую он считает по завершению каждого запроса, в динамическом режиме сначала выбран 1 процесс, поэтому у тебя отрабатывает только один запрос остальным некем обрабатываться, после чего php-fpm понимает чтонагрузка высокая и поднимает количество потоков до max_children и остальные запросы обрабатываются паралельно

Наверное все уже забыли но xml это только часть комплекса технологий, и только та что отвечает за формат хранения данных.
Вместе с xml был изобретен например язык шаблонов xslt (поддерживается всеми браузерами кстати), который позволяет выполнять кучу манипуляций с данными в xml, включая фильтрация (xpath от туда) сортировка, и т.п. и формировать неплохую динамическую страницу в браузере прямо средствами клиента без javascript!

p.s. Язык сложный для чтения, громоздкий и считается устаревшим.

доверять чему? какую атакую боишься?

cookies это файлы, буквально, на стороне клиента, сам клиент имеет к ним полный доступ, читать, удалять, изменять (подделывать), поэтому абстрактного ОТ ПОЛЬЗОВАТЕЛЯ защититься с помощью cookies не получится, но в некоторых случаях с помощью этой технологии и обфусикации можно создать сложности рядовому пользователю для этих действий.

p.s. есть еще серверные cookies, клиент их может подменить только на своем браузере (например с помощью. расширений или кастомного браузера), при https шифровании никто больше их изменить не сможет

Я тебе подправил твой вопрос, ты тегами code не попал собственно в публикуемый текст

По теме вопроса, у тебя на любое открытие страницы идет попытка доступа к $_POST[...] но при простом открытии этот массив пустой
делай хотя бы так:
$name =$_POST["username"]??"";
этот ?? делает так:
isset($_POST["username"])?$_POST["username"]:""
и ошибки не будет, а неизвестное значение подставится как ""

file_put_contents(... FILE_APPEND) дописывает содержимое в конец без пересоздания и перечитывания файла
это просто упрощенная запись конструкции
fopen(...,'a');fwrite(...);fclose(...);
если FILE_APPEND не указывать, то используется режим типа w+ (существующие файлы обрезаются в 0 размер, не существующие ошибки не вызывают)
p.s. важное замечание file_put_contents FILE_APPEND работает очень медленно, синхронизируя каждую запись с диском, я помню переписывал код на использование fopen/fwrite плюс там можно гибко задавать буфер записи

upd. на самом деле там используется просто режим 'a' и 'c' и чуть больше проверок
С интересом обнаружил по исходникам что file_put_contents умеет писать array, объединяя без разделителя значения и пропуская ключи.... век живи век учись, не знаю зачем но смешно

wss - это websocket по https, тебе точно нужно вручную заниматься всем что касается шифрованием на php?
настоятельно рекомендую для работы с websocket использовать уже готовые библиотеки например textalk websocket или ratchet pawl, вот почитай минитуториал на русском

Удивительно, что нужно сделать с windows чтобы в php номера форматировались под настройки локали (в русской там запятая стоит, но я точно помню даже со времен winxp в официальных сборках php там возвращались точки, собственно я сейчас порыл коментарии под setlocale и там твоя проблема подтверждается)
Наверное setlocale похоже не отрабатывает корректно, покажи вывод после setlocale - localeconv, точнее что там в decimal_point будет

Советую чтобы уж точно все гарантировать, любые данные, передаваемые в браузер пропускать через json_encode, это будет гарантировать корректный формат для чтения в javascript, а в браузере уже переводи к нужному виду (формат номеров там стандартизирован и не зависит от локали)

Либо использовать number_format чтобы фиксировать свой десятичный символ вне зависимости от локалей

локальная sql база данных - это sqlite

проще этой найти невозможно (база данных в файле, установка настройка и прочее это копирование файла и прописать его имя в настройках подключения), на чтение она достаточно эффективна да и на запись для большинства мелких задач более чем подходит

твоя прокси умеет работать только с http, а https сайты с ней не работают (запрос подвисает в бесконечный таймаут)
CURLOPT_SSL_VERIFYPEER, false
вот такие выкрутасы на анонимных проксях могут прокатить, так как прокси атакуют Man-in-the-middle, подменяя на невалидный сертификат, т.е. у тебя утекут либо логины пароли либо куки либо еще какая то критичная информация, а еще прокси могут подменять трафик, в лайтовом виде - подмена рекламного идентификатора и просто реклама, а в хардкоре... любые финансовые сервисы станут уязвимы

и да и нет
нет - потому что объединять в один файл не надо
да - потому что есть 'базы данных в файле', поддерживающая многопользовательский доступ и транзакции - sqlite

если ты объединишь все в один файл, то у тебя возникнет проблема многопользовательского доступа (на запись), пример - у тебя одновременно два разных человека напишут боту, два одновременных php процесса начнут читать и писать файл, и если эти события будут не последовательными, то либо в файле будет каша либо сообщения от одного 'чуть чуть опоздавшего' будут перезаписаны

Настоятельно рекомендую освоить базу данных, тем более благодаря php PDO и sqlite ничего настраивать устанавливать и тюнить не надо, все максимально удобно и просто

Проведи больше экспериментов и поймешь что та память что не освобождается не накапливается, т.е. если повторно выделить память и очистить ее, то итоговое потребление не вырастет.

Мне кажется это часть памяти занята под индексы (увеличивая размер массива увиличивается и потребление но зависимость от количества записей а не от их размера) и переиспользуется в дальнейшем

как импортируешь то? ты в свой скрипт не можешь вставить sleep между запросами?

львиную долю нагрузки базе данных на запись создают:
1. поддержка транзакций
2. перестройка индексов
3. средства защиты данных от сбоев
каждая запись на диск, которая по мнению базы данных должна быть произведена с гарантией, т.е. снабжается вызовом flush, но база данных не всегда знает когда это стоит делать а когда нет, частично это разруливается длинными транзакциями, вставляя между коммитами 100500 запросов на вставку

Так вот по каждому пункту можно временно изменить логику и настройки работы базы данных.
1. отключить транзакционные механизмы, перейдя от innodb к myisam, это может дать чуть ли не двухкратный прирост, но потребует в приложении как то игнорировать отсутствие поддержки транзакций, что не всегда просто сделать
2. отключить индексы, буквально, оставить только PK и то только там где это имеет необходимость только для импорта, после окончании импорта данных, индексы нужно будет вернуть. Однократное создание индексов на порядок если не два быстрее чем обновление индексов по каждой записи в базу.
3. отключить поддержку flush в операционной системе, буквально например опция монтирования ext4 data=writeback, база данных не будет ждать когда данные реально будут записаны на диск (есть еще опция O_DSYNC у mysql innodb, совет вообще полистать как тюнить дисковый io) но осторожно, если в это время произойдет краш сервера, данные будут испорчены, причем скорее всего безнадежно. В догонку, можно перенести журнал ext4 на другое более быстрое устройство или лучше совсем его отключить, так как при записи данные пишутся сначала в него потом на диск, на время импорта это лишние операции
И в догонку, если размер базы данных к примеру считанные сотня гигабайт, то можно временно арендовать в облаке машину с большим объемом RAM, залить базу в tmpfs и на максимально быстрой скорости импортировать данные, потом готовую базу залить обратно.

т.е. данные действия позволят, остановив работу (без этого никак) провести импорт максимально быстро и восстановить работу, пол миллиона записей это мизерный объем и если что то тормозит то исключительно из-за плохой архитектуры или реализации

у тебя твой скрипт съел 256мб оперативной памяти, ищи куда она делась, расставляй по всему своему скрипту на сервере вывод в лог значение memory_get_usage(true) с пометкой где это произошло, например:

error_log(json_encode([__FILE__,__LINE__,memory_get_usage(true)]));

это корявый но самый простой способ, полученный лог можно будет проанализировать и найти место где больше всего оперативной памяти съедено

а по уму нужно использовать полноценные профилировщики типа такого

есть 2 подхода по редактированию файлов:
1. ты находишь место в файле (буквально смещение в байтах), открыв его на чтение и запись fopen(...,'r+') читая его помощью fread или fgets или еще какой функцией (позиция будет перемещаться на следующую для чтения), перемещаешь в нужное место позицию fseek и делаешь запись fwrite или fputs, заменяя содержимое, без сдвига данных после него

этот способ подходит если заменяемые данные равны по длине с предыдущими

2. ты читаешь файл теми же функциями, и пока читаешь, записываешь в новое место построчно или посимвольно, в зависимости от способа чтения и поиска данных (т.е. у тебя будет одновременно старый файл и новый, с каким то новым именем), в тот момент когда нужно редактировать данные, ты подменяешь эти данные перед записью на новые... и продолжаешь запись до конца. По окончании удаляешь старый файл а новый переименовываешь под старым именем.

В этом методе очень важно следить за ошибками записи (например кончилось место запись не произошла) чтобы остановить код и не удалить оригинальный файл, не удостоверившись что его отредактированная копия полноценна.

Этот способ подходит для редактирования текстовых файлов, а точнее когда заменяемые данные не равны по длине оригинальным.

p.s. третий способ состоит в том что сначала файл целиком загружается в память (не важно каким способом, целиком, построчно или разобранный по объектам), в памяти он редактируется как надо, и сохраняется обратно.
В этом способе можно сохранять файл в тот же файл что и был, открыв его fopen..'w+') - что очистит файл при открытии, а значит проблемы с местом на диске менее вероятны, но если произойдет какая либо ошибка то содержимое будет потеряно, рекомендуется точно так же сначала сохранить файл в новый, удостовериться что все прошло как надо и уже после удалить оригинал и переименовать новый.

p.p.s. бывает что совмещают первый и третий способы, но относительно не всего файла а его части (например базы данных, сначала сохраняют новые данные в специальный лог файл и позже по необходимости перемещают эти данные в нужное место. Так реализуются транзакции

Некоторые файловые системы предоставляют инструменты для реализации транзакций но в php для этого нет инструментов.