Если Вы идете *, отклоняют систему, Вы могли бы использовать shell_exec () с wget, который имеет много хороших опций.
Если вы ожидаете, что ваш сайт будет масштабироваться за пределы возможностей одного сервера, вам необходимо тщательно спланировать это. Сделайте так, чтобы было возможно следующее: -
Кроме этого, все, что вы можете сделать, это провести стресс-тест вашего сайта,
Посмотрите этот доклад Расмуса Лердорфа (создателя PHP)
Специально для страницы 8 и не только.
Вы можете посмотреть этот ресурс- highscalability.com .
удачи
Некоторые люди упоминали инструменты для выявления узких мест, и это, конечно, необходимо. Вы не можете тратить продуктивное время на ускорение чего-либо, не зная, где это медленно. Но еще вам нужно знать, где находится ваша целевая масштабируемость. Стоит ли потратить пару месяцев на масштабирование вашего сайта до того же количества пользователей, что и Twitter, если его будут использовать три человека из отдела кадров? Есть ли у вас известная скорость транзакций, задержка ответа или количество пользователей в соответствии с требованиями продукта? Если да, нацелитесь на эти цифры с помощью своей стратегии оптимизации. Если нет, выясните их , прежде чем преследовать «крысу производительности».
Очень похоже: Как правильно работает PHP?
Масштабируемость - это немалая тема и, безусловно, больше материала, чем можно разумно охватить одним вопросом.
Ибо Например, для некоторых типов приложений объединения (в SQL) не масштабируются, что вызывает всевозможные стратегии кэширования и сегментирования.
Beanstalk - еще один инструмент масштабируемости и производительности на высокопроизводительных сайтах PHP. Как и memcache (другой вид).
Самая большая проблема для масштабируемости обычно - это общие ресурсы, такие как СУБД. Проблема возникает из-за того, что СУБД обычно не имеют возможности ослабить гарантии согласованности.
Если вы хотите повысить масштабируемость при использовании чего-то вроде MySQL, вам необходимо изменить дизайн схемы, чтобы ослабить согласованность.
Например, вы можете разделить схему базы данных, чтобы иметь вашу нормализованную модель данных для записи, и реплицированную денормализованную часть только для чтения для 90% операций чтения. Данные, доступные только для чтения, могут быть распределены по нескольким серверам.
Другой способ увеличить масштабируемость базы данных - разделить данные, например, разделить данные в базу данных для каждого отдела и объединить их либо в ORM, либо в СУБД.
Разрабатывайте свой сайт, используя надежные методы ООП. Вам потребуется, чтобы ваш сайт был модульным, поскольку не все узкие места в производительности очевидны с самого начала. Будьте готовы к рефакторингу частей вашего сайта по мере увеличения трафика. Первое написанное мной предложение поможет вам сделать это проще и безопаснее. Кроме того, используйте разработку, управляемую тестированием, поскольку рефакторинг означает появление новых ошибок, а хорошая TDD позволяет выявлять их до того, как они попадут в производство.
Отделите как можно больше кода на стороне клиента от кода на стороне сервера, поскольку они, вероятно, будут обслуживаться с разных серверов, если трафик вашего сайта это оправдывает.
Прочтите статьи (прочтите, например, советы YSlow).
GL
В порядке важности:
Если вы запускаете PHP, используйте кэш опкодов, например APC . (Это достаточно важно, чтобы быть встроенным в следующее поколение PHP.)
Используйте YSlow или Google Page Speed , чтобы определить узкие места. (Это позволит выявить структурные проблемы вашего веб-сайта, которые влияют на производительность как клиента, так и сервера.)
Убедитесь, что ваш веб-сервер отправляет правильный заголовок Expires для статического содержимого (изображения, Javascript, CSS), чтобы браузер мог правильно кэшировать его . (YSlow также предупредит вас об этом. )
Используйте ускоритель HTTP, например Varnish . ( Это изображение говорит само за себя - а у них уже есть ускоритель HTTP.)