[ utx ] Как не надо забывать про логгеры
„Интересно“ — думаю, — „Что это у меня так тормозит ютх с ответом? До безобразия, буквально, тормозит, разве ж можно так?“ По идее, конечно, безумные утки, лочащие базу,[&] портят мне жизнь, но в самом-то скрипте всё должно работать нормально, и в девяноста процентах случаев он должен вылетать без всяких обращений к БД в принципе, вытянув картинку из кэша и вышвырнув её в поток.
Идём смотреть. Видим файл utx_log.txt. Обращаем внимание на то, что его объём достиг скромных тридцати трёх мегабайт. Молча высказываем себе всё, что мы о себе думаем (так как это второй или третий случай уже, и прежде всё решалось банальным echo -n > utx_log.txt вместо того, чтобы поправить код, который эти тридцать три мегабайта нагенерировал). После этого отправляемся переписывать старый скрипт и делаем то, что нужно было сделать много месяцев назад — ставим в имя файла текущую дату.
Оказывается, я не только программирую на пхп со словарём, но и оптимизировать умею только в теории, на уровне технического консультирования клиентов. Такую очевидную (после недельного периода работы логгера накапливается два-три мегабайта) ошибку упустить... Bleh.
Интересно, всё же, как обрабатывается fopen('filename','a') внутри — хочется надеяться, что пхп не открывает всё это содержимое в поисках конца файла... И не менее интересно, почему нету какого-нибудь режима открывания "f", который бы открывал файл на запись и ставил бы указатель в начало, а не в конец — это должно быть (при взгляде со стороны) быстрее. RTFM: "r+".
