Я использую общий хостинг и не могу включить APC. Об этом была ветка Вот, и единственная предложенная причина была для безопасности (php-cgi vs mod_php). Я запросил хост, и они сказали, что это из-за соображений производительности, в частности, из-за того, что ввод-вывод выйдет из строя. Я действительно не понимаю этого - конечно, с кешем опкодов с общей памятью было бы Меньше Ввод / вывод? В принципе, если бы я создавал компанию по виртуальному хостингу (не то чтобы я мог!), Я бы подумал, что будет иметь смысл использовать кеш (если разрешена безопасность) для повышения производительности для всех клиентов.
Может ли кто-нибудь пролить свет на это для меня? TIA
Я бы сказал, что планы APC на общем хостинге - не самая лучшая идея.
Ответ вашего хостинга правильный, но это не единственная причина.
Когда вы получаете общий хостинг, вы должны знать, что вы не единственный, кто использует сервер, на котором размещен ваш сайт. В зависимости от сервера хостинговой компании может быть 300 (или более) клиентов, которые также размещают свои сайты на этом компьютере.
Часто на этих сайтах есть МНОГО php файлов. Например joomla 1.6 управляемый сайт имеет ~ 3000 php (~ 10 МБ) файлов (включая сайт и админку). Представьте, что все эти 300 клиентов используют платформу Joomla, а сайты
Это означает, что у всех этих клиентов будет ~ 900000 файлов для кэширования - ~ 3000 МБ ОЗУ будет использоваться только для кеширования файлов php. Как вы знаете, в APC вы также можете хранить «Записи пользовательского кеша», где обычно можно хранить настройки или сериализованные объекты. Я не могу сказать, сколько там ОЗУ будет, потому что это зависит от того, что вы храните, но скажем еще 50-100 МБ.
На данный момент мы использовали около 3,1 ГБ оперативной памяти.
Теперь добавьте немного оперативной памяти, необходимой для работы основных служб - Apache, FTP, PHP, MySQL, PostgreSQL, SendMail и средств резервного копирования сервера. Вы, вероятно, получите где-то около 5-6 ГБ оперативной памяти, которая будет использоваться почти постоянно.
Другие проблемы с APC возникают, когда вы кешируете - все могут видеть, что вы кешировали (насколько я знаю). Поэтому вам, вероятно, потребуется зашифровать то, что вы храните - для этого потребуется больше процессора, потому что вы будете все время шифровать / дешифровать. Также, если кто-то случайно очистит все кешированные файлы / записи пользователей, сервер сойдет с ума, пытаясь повторно кэшировать.
Суть в том, что ни один системный администратор не возьмет на себя всю боль в * ss, чтобы включить и поддерживать APC. Это тоже не выгодно для компании. Они предпочли бы, чтобы им платило на 300 клиентов больше, чем иметь дело с APC и гадать, не выйдет ли из строя их сервер или что-то пойдет не так в любой момент.
Лучшим решением было бы, если бы клиент получил (управляемый) выделенный сервер. Таким образом, клиент будет единственным, кто размещает сайт на этом сервере, и он сможет попросить службу поддержки установить все, что захочет, на сервере. Это будет намного проще и убережет клиентов, системного администратора и хостинговую компанию от седых волос :)
Надеюсь, это поможет вам лучше понять, почему APC не включен в общий хостинг.
За: http://www.php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask
apc.mmap_file_mask строка
Если скомпилирован с поддержкой MMAP с использованием - включить-mmap это маска file_mask в стиле mktemp, передаваемая модулю mmap для определения того, будет ли ваша область памяти mmap поддерживаться файлами или совместно используемой памятью. Для прямого mmap с файловой поддержкой установите что-нибудь вроде /tmp/apc.XXXXXX (ровно 6 Иксс). Чтобы использовать shm_open / mmap в стиле POSIX, поместите .shm где-то в твоей маске. например /apc.shm.XXXXXX Вы также можете установить его на / dev / ноль использовать ваше ядро / dev / ноль интерфейс с анонимной памятью mmap. Если оставить его неопределенным, это вызовет анонимный mmap.
При использовании файловой поддержки это определенно увеличит ваш ввод-вывод в зависимости от объема трафика, поступающего на сервер.
Это убьет производительность любого совместно используемого хоста, если у вас не будет достаточно памяти для хранения каждого файла PHP, загруженного в память. Когда у вас есть целая группа пользователей, пытающихся кэшировать файлы, которые могут редко попадать, сервер начинает подкачку, что убивает производительность всего на этой машине.
В соответствии с https://stackoverflow.com/questions/1053810/php-apc-what-happen-when-apc-cache-is-full, кеш очищается, когда память заполнена и если ttl равен 0. Если не установлен в ноль, будет использоваться механизм LRU (Least Recently Used).
Мне кажется, всегда выгодно использовать APC.
@tftd указал основные причины, по которым APC, Memcached и т. д. не включены в общий хостинг. Но вариант использования может возникнуть, если ваш общий сервер на самом деле не является общим, а используется только вашими собственными проектами (или клиентами веб-дизайна / разработки, и если вы НЕ предоставляете им доступ к FTP / панели), тогда этот сервер все равно может извлечь выгоду из APC / Memcached / и т. Д.
В любом случае, я полагаю, что проблема ввода-вывода зависит от ОЗУ, доступного APC, поскольку он будет постоянно пытаться аннулировать некоторые записи и кэшировать новые, если доступная ОЗУ мала или количество сайтов / файлов PHP очень высокий (частый случай в виртуальном хостинге). Это не должно быть проблемой, если оперативной памяти достаточно и вы следите за apc.php (информационная страница APC).
Кроме того, преимущество APC будет лучше всего ощущаться на сайтах с умеренным / высоким трафиком, поскольку кеширование редко посещаемых файлов PHP не имеет большого значения.