Вопросы Теги

Кэш страницы в PHP, который обрабатывает параллелизм?

pypdf делает то, что я ожидаю в этой области. Используя следующий сценарий: 

#!/usr/bin/python
#

from pyPdf import PdfFileWriter, PdfFileReader

with open("in.pdf", "rb") as in_f:
    input1 = PdfFileReader(in_f)
    output = PdfFileWriter()

    numPages = input1.getNumPages()
    print "document has %s pages." % numPages

    for i in range(numPages):
        page = input1.getPage(i)
        print page.mediaBox.getUpperRight_x(), page.mediaBox.getUpperRight_y()
        page.trimBox.lowerLeft = (25, 25)
        page.trimBox.upperRight = (225, 225)
        page.cropBox.lowerLeft = (50, 50)
        page.cropBox.upperRight = (200, 200)
        output.addPage(page)

    with open("out.pdf", "wb") as out_f:
        output.write(out_f)

получающийся документ имеет поле для обрезки, которое является 200x200, указывает и запускается в 25,25 точках в поле медиа. Поле обрезки является 25 точками в поле для обрезки.

Вот то, как мой демонстрационный документ смотрит в профессионале акробата после обработки с вышеупомянутым кодом: crop pages screenshot

Этот документ появится пробел, когда загружено в Acrobat Reader.

6
задан WalterGR 4 August 2009 в 09:46
поделиться

5 ответов

Кажется, у PEAR :: Cache_Lite есть какая-то защита для решения проблем параллелизма.
Если вы посмотрите руководство конструктора Cache_Lite :: Cache_Lite , у вас есть следующие варианты:

fileLocking включить / отключить блокировку файлов. Можно избежать повреждения кеша при плохих обстоятельства.

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

readControl включить / выключить контроль чтения. Если включено, контрольный ключ встроен в кеш-файл и этот ключ сравнивается с рассчитанным после чтение

readControlType Тип контроля чтения (только если включен контроль чтения). Должен быть md5 (для хеш-контроля md5 (лучше, но самый медленный)), 'crc32' (для хеша crc32 контроль (немного менее безопасный, но быстрее)) или strlen (для длины only test (самый быстрый))

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


Вы также можете взглянуть на Zend_Cache_Frontend_Output , чтобы кэшировать страницу, используя что-то вроде Zend_Cache_Backend_File в качестве бэкэнда.

Кажется, что он также поддерживает некоторую безопасность - - то же самое, что Cache_Lite уже дал вам (так что я не буду копировать и вставлять второй раз)


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

В любом случае,

2
ответ дан 17 December 2019 в 07:07
поделиться
  1. В Linux, как правило, файл остается «открытым» для чтения, даже если он «удален», пока процесс не закроет файл. Это что-то встроенное в систему, и иногда может вызывать огромные расхождения в размерах использования диска (удаление файла 3G, когда он все еще «открыт», будет означать, что он все еще выделяется на диске как используемый, пока процесс не закроет его) - я не уверен, есть ли то же самое истина под Linux.
  2. Предполагая, что файловая система с журналированием (большинство файловых систем Linux и NTFS) - тогда файл не должен рассматриваться как «созданный», пока процесс не закроет файл. Он должен отображаться как несуществующий файл!
0
ответ дан 17 December 2019 в 07:07
поделиться

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

0
ответ дан 17 December 2019 в 07:07
поделиться

Предполагая, что файловая система с журналированием (большинство файловых систем Linux и NTFS) - тогда файл не должен рассматриваться как "созданный", пока процесс закрывает файл. Он должен отображаться как несуществующий файл!

Нет, он виден сразу после создания, вам нужно заблокировать его. Однако переименование атомарно. Таким образом, вы можете open (), write (), close (), rename (), но это не предотвратит повторное создание одного и того же элемента кэша дважды за одно и то же время.

Кэшированный файл был удален, потому что он устарел . Приходит запрос на этот файл, и файл находится в процессе воссоздания. Во время этого поступает еще один запрос на файл.

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

0
ответ дан 17 December 2019 в 07:07
поделиться

Я бы хотел изменить один из существующих кешей. Кеш Zend Framework должен помочь. Если нет, я бы его изменил.

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

Это решит ваши проблемы с ACID. Вы можете установить блокировку для чьего-либо обновления на очень короткий период или, возможно, полностью пропустить кэш для этого двустороннего цикла, в зависимости от нагрузки / емкости вашего сервера и стоимости создания кэшированного содержимого.

Джейкоб

1
ответ дан 17 December 2019 в 07:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: