rPman

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 для этого нет инструментов.

Связывай письма не по теме а по хидерам в письмах: In-Reply-To, References и не стандартный майкрософтовский Thread-Index, по крайней мере так было раньше, маловероятно что что то еще добавилось

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

Второй - как много данных

Третий - на сколько сложные запросы по поиску и фильтрации у тебя есть

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

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

Так же сериализовать в файл можно не сразу все данные а по объекту на файл (файловая система ОС - отличная key-value база данных, удобная быстрая, но без нормальной поддержки многопользовательского доступа, точнее можно с помощью блокировок но сложно), благодаря чему можно решать очень сложные задачи без оверхеда на место на диске, процессор и лишний кодинг. Недостаток этого подхода - индексы реализовывать придется самому.

p.s. по теме конкретно сформулированного вопроса, гугли CRUD, это готовые инструменты по create,read, update, delete объектов, которые тут же описываешь. Так или иначе эти механизмы мого кто реализует в своих фреймворках

но начинающему настоятельно рекомендую пройти весь путь от самописных структур данных и работе с sql

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

select .. from ... where ... and (:product_group is null and `product_group` is null) or (`product_group` = :product_group)

чтобы один и тот же параметр в запросе использовать несколько раз, используй пользовательские переменные (живут до конца сессии), т.е. выполняешь два запроса, первый
set @product_group=:product_group
а уже в самом запросе вместо :product_group используешь @product_group