- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Кто вам такую глупость сказал?
Кеширование опкода заметно прибавляет производительность. На скриптах без сложных запросов к БД, файлового ввода/вывода, интенсивных вычислений разница может быть даже на порядок. И в любом случае она будет.
в реальной жизни главный тормоз сайта - это запросы к базе, которые могут обрабатываться и пару секунд, над ними и нужно думать как кешировать, а кеширование пхп кода - это ускорение на 0,000001 сек, что на том же вордпресе с генерацией страницы в 1-2 сек будет не заметно )))
Как будут себя вести кешеры в случае с вариантом 2, но apache в режиме mpm-itk?
Также, как prefork, основное отличие ITK в смене пользователя, после разбора запроса.
И насчет первого варианта: я так понимаю в данном случае порождается дополнительный процесс php, кешер сохарняет опкод, затем скрипт отрабатывает и процесс завершается.
Кому в таком случае будет нужен кешированный опкод? И куда он девается?
Процесс не порождается на каждый запрос а живёт определённое конфигурацией количество запросов... Это время кеш актуален.
в реальной жизни главный тормоз сайта - это запросы к базе, которые могут обрабатываться и пару секунд, над ними и нужно думать как кешировать, а кеширование пхп кода - это ускорение на 0,000001 сек, что на том же вордпресе с генерацией страницы в 1-2 сек будет не заметно )))
Вы пририсовали очень много лишних нулей. На разбор php скрипта необходимы ресурсы процессора. А на его считывание ещё и неспешный дисковый ввод/вывод - без кешера он не будет гарантированно лежать в кеше файловой системы, к тому же обработанный скрипт куда компактнее. Всё это не только занимает определённое время, но и кушает ресурсы, которые могли бы быть потрачены на обработку запросов mysql. И в условиях наличия конкурентных запросов это вполне себе заметно.
Кеширование же данных на уровне приложения или веб сервера это уже совсем другое дело. Одно другого не заменит. Кстати, APC умеет и данные пользовательские кешировать, и работает в этой ипостаси быстрее того же memcached...