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

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

А если сделать кэширование данных

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

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

примерно так:

if ( $fp = fopen($filename,'r-') ) {

fseek($fp, $offset);

$rec = fread($fp, 4);

$newrec = @unpack ('f', $rec);

}

fclose($fp);

return @$newrec[1];

---------- Добавлено 11.01.2020 в 19:36 ----------

1. 4150 файлов, 4,3 Гб, каждый файл около 1 Мб.

2, 3. Да. Если второй раз выполнить точно такой же запрос (с той же широтой и долготой), данные возвращаются мгновенно.

А если немного изменить широту/долготу, тут уже 50:50, или 0.5 сек, или 30-40 сек.

---------- Добавлено 11.01.2020 в 19:41 ----------

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

Но у меня подобный проект (с чтением данных из большого количества файлов) работает уже 8 лет на другом сервере, VPS, с гораздо более скромными системными параметрами. Скрипты устойчиво выполняются пусть не за 0.5 с, так за 2-3 с.

На выделенном сервере, как я ожидал, всё будет летать. Но нет - ситуация совсем другая и грустная.

Такое впечатление, что что-то с настройками файловой системы.

Corvus, это меняет дело

if ( $fp = fopen($filename,'r-') ) {

fseek($fp, $offset);

что такое "r-" вам нужно использовать ключ "r"

какой $offset насколько он велик

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

скидываем кеш файловой системы и тестируем скорость чтения диска

sudo /sbin/sysctl -w vm.drop_caches=3

dd if=tempfile of=/dev/null bs=1M count=1024

какое значение скорости это показало?

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

Aisamiery, похоже в пакетах для debian 10 такого уже нет. Есть php-excimer https://www.mediawiki.org/wiki/Excimer - по смыслу вроде похожее.

Dreammaker,

https://github.com/tideways/php-xhprof-extension

компилируется, подключается модуль, рестартится php

danforth, оно то можно, но у меня вот при переезде на дебиан 10 и php7.3 стандартный mbstring.so почему-то поломался. При его подключении просто виснет php и всё. При этом, если как php-cli запускать - всё ок. Если вызвать php7.3-cgi через консоль - запускается. Но только подключаю через FCGIwrapper к апач - сайт виснет, хотя на 7.0 всё работало. Благо через композер когда-то зачем-то поставили симфониевский полифил для mbstring и она подхватился после отключение mbstring. В паре месте подпилили и заработало.

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

мы в продакшене используем на хорошей такой нагрузке для php 7 расширение что выше сказали https://github.com/tideways/php-xhprof-extension

Ставится и собирается вот так https://tideways.com/profiler/xhprof-for-php7

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

Для примера, на дев сервере все работало очень быстро, а на проде отрабатывало за 10 секунд, то есть на деве ошибка не проявилась и дебажить было нечего, а на проде показало что 10 секунд отрабатывает session_start()

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 1.44716 s, 742 MB/s

hdparm выдаёт:

/dev/sda

Timing cached reads: 3590 MB in 2.00 seconds = 1795.36 MB/sec

Timing buffered disk reads: 290 MB in 3.02 seconds = 96.08 MB/sec

/dev/sdb:

Timing cached reads: 3580 MB in 2.00 seconds = 1789.78 MB/sec

Timing buffered disk reads: 474 MB in 3.00 seconds = 157.90 MB/sec