Сильно варьируется время работы PHP-скрипта

а что с интернетом у вас, может скорость соединения лагает?

пинги сервера ок?

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

Ну смотрите.

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

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

3. нужно перенастроить максимальное число возможных открытый файлов на VDS, вероятно бъет в лимит и больше не может открыть. Возможно в этом и причина. В SSH введите sudo ulimit -n 32768 и и повысить /proc/sys/fs/file-max в текстовике. Посмотреть другие лимиты ulimit -a

Пинги нормальные, интернет тоже. Время выполнения скрипта я подсчитываю в самом скрипте, то есть без учёта затрат на передачу данных по сети. Если скрипт вызывать не через веб, а из командной строки через шелл, работает он так же неустойчиво.

---------- Добавлено 10.01.2020 в 16:25 ----------

Да, я так делал. Отображал и время выполнения отдельных операций, и затраты памяти.

В том-то и проблема, что при одном запуске скрипта каждая операция чтения файла занимает, условно, 0.001 секунды и общее время работы скрипта 0.5 секунд, а в другом каждая операция чтения 0.1 секунды и общее время 40-50 секунд.

Вычисления в скрипте выполняются буквально за 0.2 секунды. То есть основное время уходит на чтение файлов, оно-то и занимает очень много времени.

---------- Добавлено 10.01.2020 в 16:29 ----------

Спасибо! Попробую то, что Вы сказали.

Как думаете, есть ли смысл помещатьисходные данные в БД? Их общий размер около 9 Гб, обновляются они несколько раз в сутки. Будет ли выигрыш по времени чтения, и стоит ли игра свеч, ведь залив в БД такого объёма будет идти, вероятно, весьма долго.

Просто зная широту и долготу точки, я однозначно знаю, по какому смещению читать данные из файлов. Казалось бы, в таком случае чтение из файлов должно работать быстрее, чем чтение из БД?

---------- Добавлено 10.01.2020 в 16:32 ----------

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 125436

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited

open files (-n) 500000

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 10240

cpu time (seconds, -t) unlimited

max user processes (-u) 50000

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

По идее этого должно быть достаточно?

А использовать сервисы по определению геоположения не то, на javascript, тот же яндекс? 9 гигабайт не мало для реалтайма, я думаю будет лучше, чем последовательно читать. Через БД можно оптимальнее обойти, если еще построить логику с лимитированием и индексами. Плюс можно выставить кеш на БД.

У вас последовательно с файлов читает кусками или построчно? если построчно, это очень медленные операции.

К примеру, скорость выборки 10000 случайных записей 1 - 150 млн занимает на обычно дохлой VPS при использовании MongoDB 0.1 сек и размер >9 gb с индексами.

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

Реально количество файлов какое ? Всего их сколько ? Объем какой ?

Вторичный вызов того-же запроса приводит к тому-же времени выполнения ?

Вызов быстрого всегда быстр ?

Скорее всего надо как-то в сторону файлового кеша и файловой системы смотреть.

Но вообще "профилируйте", наставляйте логов и смотрите где время уходит.

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

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

Под "линуксы" я помнится читал что есть ФС заточенные под подобного рода работу, т.е. работу с большим количеством файлов.

БД с индексами, скорее всего не даст вам никакого буста, если вам реально нужно содержимое этих файлов.

еще выполнить

sudo sysctl -w fs.nr_open=500000

sudo sysctl -p

забыл упомянуть, что ulimit -n 32768 && ulimit -a нужно применить на том пользователе, под которым у вас запускается процесс. Например пользователь вебсервера www-data

перейти под пользователя sudo -u www-data sh

дальше ulimit -n 32768 && ulimit -a

exit

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

Правильно. Слушать не надо - думайте.

А файловая система по вашему мнению что, для чтения файла по пути последовательно весь диск читает :) ?

Врубите мозг наконец.

ФС - это такая СУБД для управления файлами.

И надеяться, что любая другая СУБД будет выдавать по одному индексу (пути) данные быстее, чем ФС - это очень-очень странно.

Уж не говоря о том, что ФС кешируется "на все деньги", что есть... при правильных настройках.

А SQL сервера, как правило нет.

_SP_, мы за файл говорим или за файловую систему. Файл читается последовательно, в индекс файловой системы попадает например название этого файла, содержимое файла не разбивается по индексам.

В случае же базы данных мы можем побить множество нужных кусков данных под индексы и обращаться к этим кускам быстро отталкиваясь от своих задач. Аналогия, равносильно предположим создать 1000000 файлов и название указать широту, внутри файла же будет вся информация по городам с этой широты. так мы можем быстро открыть файл имея значение широты. Потому как файловая система строит индекс по названию файла. Но кто в здравом уме будет создавать столько файлов и гемороится, когда можно намного быстрее и проще сделать это с базой данных. Это вам любой практикующий разработчик скажет, что вы плывёте в другое русло.

Автор написал про 9 гб данных и 4000 файлов. несложно посчитать размер каждого файла и потом с этого размера последовательное чтение да еще и с поиском нужного значения.

Не можете.

Если ТСу нужно содержимое файла, то вы не можете ничего побить.

Если он обращается к содержимому по пути, то это будет не медленнее, чем обратиться по индексу, а может быть быстрее.

Если файл невелик, то разницы "считать весь / считать часть" не будет (чтение всё-равно идет блоками).

Если файл невелик, то чтение из него не будет медленнее, чем "достать через индекс из БД только нужное", а может быть быстрее.

Разумеется, если ТС что-то там "перебирает и ищет", то делать так НЕ НАДО, надо строить индексы итп.

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