- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Разрабатываю систему. Пока, кеш работает только в шаблонизаторе, Nginx не установлен, PHP установлен как модуль Apache. Время генерации страницы в среднем 0.02 секунды. Но функционала реализовано далеко даже не половина от запланированного. Сейчас идет борьба ООП против производительного кода. Естественно, подключу Memcached, и все такое, но...
Интересует, какие цифры считаются адекватными для заурядной системы блога без кеша и с полным динамическим кешированием. Может кто-то может посмотреть за сколько загружаются их сайты, указать систему, или проверить на самописах с различными типами оптимизации.
Вообще, я считаю нормальным число в 0.2 секунды. Ведь если учесть время на коннект, днс ресолв, это получиться заурядных 500-800 миллисекунд на вейт бифор ренд. Как вы считаете? Какие методы оптимизации для вас самые радикальные? Обращаете ли вы на это внимание? :popcorn:
Можете с помощью гугла проследить время загрузки, получить рекомендации, сравнить с конкурентами, вообще для блога 1 секунды загрузки страницы просто за уши)
Content-pro, спасибо, я использую WinGridCache для просмотра Xdebug карты выполнения скрипта. :) А HTML оптимизировать - дык, сразу пишу такой. А вот в PHP я еще новичок. Хочется красиво, кратко, абстрактно, а получается либо медленно, либо 3 цикла в цикле))).
---------- Добавлено 08.05.2013 в 01:08 ----------
Еще такой вопрос, может кто-то задумывался. У меня классы вынесены в отдельные файлы. Соответственно при запуске главного скрипта, подключаются все нужные классы через __autoload() во время выполнения тела скрипта. На подключение затрачивается больше 1 миллисекунды! Классов у меня не мало, но даже 30 миллисекунд потерять только на подключении кода я не хочу. Как можно оптимизировать это дело? Nginx делает это? Может можно кешировать в память файлы как-то? Memcached нормальный вариант? По идеи -3мб ОЗУ единожды при первом запуске сервера, это ведь не так много. А с памяти скрипт будет браться быстрее. Насколько это безопасно?
Если не брать в расчет highload проекты, то на страницу допустимо время генерации до 0.05c. После могут появляться визуально различимые задержки. Для простого блога время работы php не должно превышать 0.01 и еще 0.01 на работу с базой.
Еще стоит обратить внимание, что время генерации на локолке и на сервере это две разные цифры.
Не стоит винить ООП в медлительности.
Слабое место это запросы к базе данных. Их должно быть мало и они по возможности должны быть простые. Например, при работе с большими таблицами чаще выгоднее сначала из одной выбрать все нужные записи и только потом одним запросом подтянуть мета-данные из второй.
Второе слабое место - это работа с большими массивами данных. Для блога их просто не должно быть.
ortegas, по времени загрузки, сначала сделайте, что требуется, а потом уже думайте, что оптимизировать. С большой вероятностью самое узкое место окажется не там где вы думаете, и часто можно просто закешировать вывод тем или иным способом.
Ещё раз повторюсь - сначала сделайте, ибо можно столько думать, что так и не приступить к реализации.
По вопросам загрузки классов - гляньте в сторону lazy loading, а также установите на сервере, если нет какие-то кешеры байт-кода, например, APC.
Еще такой вопрос, может кто-то задумывался. У меня классы вынесены в отдельные файлы. Соответственно при запуске главного скрипта, подключаются все нужные классы через __autoload() во время выполнения тела скрипта. На подключение затрачивается больше 1 миллисекунды! Классов у меня не мало, но даже 30 миллисекунд потерять только на подключении кода я не хочу. Как можно оптимизировать это дело? Nginx делает это? Может можно кешировать в память файлы как-то? Memcached нормальный вариант? По идеи -3мб ОЗУ единожды при первом запуске сервера, это ведь не так много. А с памяти скрипт будет браться быстрее. Насколько это безопасно?
APC кеш отлично справляется с этой проблемой. А сколько у вас файлов/классов подключается?
ortegas, по времени загрузки, сначала сделайте, что требуется, а потом уже думайте, что оптимизировать. С большой вероятностью самое узкое место окажется не там где вы думаете, и часто можно просто закешировать вывод тем или иным способом.
А-ай.. он не слышит у него ж написано - идеалист... И про преждевременную оптимизацию, и про экономию на спичках..
Я искренне надеюсь, что "всё получится".. только чем-то напоминает про того Петю, который "делал всё правильно, но долго"
Соответственно при запуске главного скрипта, подключаются все нужные классы через __autoload() во время выполнения тела скрипта.
Если делать "правильно", то через _autoload классы подключаются только при необходимости. А время выполнения можно уменьшить, если "слить" все классы в один файл и использовать оп кэшер (APC, XCache, eaccelerator - для верности можно самостоятельно замеры провести)... Насчёт ускорения за счёт кэширования в память - файлы кэшируются на уровне файловой системы.
Ещё можно получить статистику с любых сайтов - в т.ч. с gov, gov.ru, с блогов на вордпресс (лучше не первых попавшихся, а более-менее известно-популярных), сравнить время открытия страниц на хабре (можно считать, что оно допустимо) и прочих сайтах.
Что ДЛЯ ВАС является допустимым - решайте сами.
Это вы наверное о кэшированной версии говорите. А здесь может и вообще статик выводиться, а потом уже в отдельном потоке всякие формальности.
Еще стоит обратить внимание, что время генерации на локолке и на сервере это две разные цифры.
Именно. Под виндовском файловая система медленная, а вот на сервере, на Debian, генерация происходит в 3 раза быстрее. Поэтому, я так понял файловая система сейчас является костылем.
12 классов, 4 конфигурационных файла, 2 файла локализации.
Ну а без дополнительных модулей это можно реализовать, то-есть, на уровне кода? Именно только кеширование файлов?
:) Чем быстрее, тем лучше.
Вот у меня на Windows 8, Wordpress без кэша генерирует главную страницу за 4 секунды, а под Debian, 1 секунда. Вот такое вот.
Ну а без дополнительных модулей это можно реализовать, то-есть, на уровне кода?
Слить все классы в один файл, убрать лишние пробелы.. - вполне на уровне кода.. поможет ли
Насчёт помещения в память:
http://www.phphighload.com/2012/06/blog-post_13.html
ещё одно подтверждение - мерять и мерять...
p.s. можно и демона написать, который будет постоянно в памяти висеть и соединение с БД открытым держать...
На Debian работа с файлами почти в 1000 раз быстрее. Поэтому, решил провести специфическую для Windows оптимизацию файлового кеширования. Единственным вариантом для PHP 5.5 оказалось включение Zend Optimizer Cache Ext. И действительно, в пару раз выросла производительность.