Большие файлы и нагрузка на сервер

Здравствуйте.
Возник такой вопрос.

Есть движок игрового сайта.Игры располагаются в обычных txt файлах (вместо бд), ну тоесть не сами игры, а название, описание, размер и т.п
Для каждой категории отдельный файл.Тоесть для аркад arcady.txt, для гонок gonki.txt
Игры размещаются в формате по 1 на строку.Тоесть если в файле 10 строк, значит это 10 игр.

Теперь вопрос.Если скажем каждый из этих файлов весит более 1-2 mb, как сильно это повлияет на нагрузку сервера?
Ну тоесть в этом самом движке, например, что бы вывести на страницу определнное кол-во игр, сначала файл заносится в массив через file(), потом все это дело парсится и выводится.
Я так понимаю, что если скажем на сайт зайдут 10 человек, то скрипт 10 раз этот самый файл откроет, для того что бы вывести игры, или же только один раз?

Если он откроет 10 раз этот файл. то вопрос, как сделать что бы только 1 раз?Я так понимаю нужно копать в сторону flock и т.п, или может быть в сторону кэширования?
Вобщем, суть вопроса, как снизить нагрузку на сервер, ибо открывать каждый раз через file() 1-3 мб файлы слишком затратно для сервера, мне кажется...

(Отредактировано автором: 10 Сентября, 2013 - 21:55:56)

Даже если размер «файловой базы» будет в считанные килобайты — и то БД будет уже быстрее. В случае мегабайтных размеров разница в скорости будет вообще несопоставимая.

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

используйте сериализацию в таком случае

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

Если проблемы нет и просто интересно на будущее - перепишите всё на использование базы данных. Это единственное нормальные и адекватное решение.


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

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


json, помнится, быстрее работает. Да и места (==памяти) занимает меньше.

-----
PostgreSQL DBA

Помниться статья на хабре с тестами. Походу они одинаково по скорости, или разница незначительная.
Но все же ТС Вам стоит переделать все с файлов на БД. Ибо с возрастанием нагрузкы файлы перестанут справляться со своей задачей. И я не поверю что Вы сможете реализовать все что есть в БД на файлах в ПХП

считывайте файлы построчно fgets, если в один момент времени нужна одна игра.

-----
Чем больше узнаю, тем больше я не знаю.

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

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


Я честно говоря не вьеду, причем тут сериализация...
Можно подробнее мысль изложить пожалуйста?

А вообще, стоит ли игра свечь?
Если файлы будут не более 1-3 мб?БУдет ли это сильно затратно для сервера?Или можно оставить как есть?

(Отредактировано автором: 11 Сентября, 2013 - 16:32:33)

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

Например, очевидно ли вам, что file заметно медленнее explode(PHP_EOL, file_get_contents('file'))? А это так.

-----
PostgreSQL DBA

Насчет explode(PHP_EOL, file_get_contents('file')) не знал, учту.
Хотя потратив 1 минуту на гугл обнаружилась вот такая интересная статься по этому поводу - http://a-develop[dot]ru/blog/279

(Отредактировано автором: 11 Сентября, 2013 - 17:00:55)

Что как раз подтверждает:

-----
PostgreSQL DBA

У кого еще какие соображения? Кстати вопрос, заметил что если хранить данные в utf-8 то файл получается больше в два раза по сравнению скажем с win1251.
Cтоит ли хранить данные в win 1251?

не стоит

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

Хотелось бы конкретики, почему не стоит


Сейчас провел эксперимент, на одинаковом железе файл весом в 55mb (utf-8) функция file() прочитала за 1.5 сек.
А вот файл с тем же кол-вом строк, но в кодировке win-1251 (вес получился 34mb) за 1.1 сек...разница есть

(Отредактировано автором: 12 Сентября, 2013 - 01:12:05)

перекодировать 55М тоже разница есть

юникод используется для устранения проблем с кодировками. размер файлов значения не имеет

а чтобы не было проблем со скоростью используются сервера баз данных
где не надо читать 55М для получения десятка строк

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore