- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Неделю попилил свой самописный движок http://123-realty.ru/, удалось достичь 10-20 кратного сокращения времени загрузки страниц. От основных тормозов удалось избавится с помощью кеширования.
Делюсь опытом:
1. Переписал запросы, в основном убирал условия в where, использовал join.
2. Используя explain создал нужные индексы.
3. Сделал кеширование запросов на уровне веб-приложения, serialize, unserialize. Разделил часто выполняемые запросы, установил время хранения кеша для разных элементов страницы.
4. Поставил связку nginx+apache+mysql
Кому интересно задавайте вопросы.
Это больше похоже на пиар вашего сайта.
Если бы вы хотели поделиться опытом - написали бы все по пунктам и с объяснением.
Неделю попилил свой самописный движок 123-realty.ru, удалось достичь 10-20 кратного сокращения времени загрузки страниц. От основных тормозов удалось избавится с помощью кеширования.
Делюсь опытом:
1. Переписал запросы, в основном убирал условия в where, использовал join.
2. Используя explain создал нужные индексы.
3. Сделал кеширование запросов на уровне веб-приложения, serialize, unserialize. Разделил часто выполняемые запросы, установил время хранения кеша для разных элементов страницы.
4. Поставил связку nginx+apache+mysql
Кому интересно задавайте вопросы.
Хы-хы-хы, этим вы добились сокращения времени генерации страниц, но не их загрузки
PS: есть статья по сокращению времени выполнения php-сценариев, вот только урл не помню, там очень хорошо и наглядно описано, как сократить время выполнения php-сценария, какие циклы лучше использовать ну и т.п. (буду благодарен за ссылку если что)
а с чего решили что join быстрее where? По сути join всегда тяжелее, так как является влложенным запросом
1. Переписал запросы, в основном убирал условия в where, использовал join.
2. Используя explain создал нужные индексы.
Лучше разбейте большие запросы на несколько мелких, собирайте результат в php и кешируйте. Часто помогает.
3. Сделал кеширование запросов на уровне веб-приложения, serialize, unserialize. Разделил часто выполняемые запросы, установил время хранения кеша для разных элементов страницы.
Немного не понятно, что именно кешируете. Я всегда кеширую данные, многие знакомые - блоки html. У них явно быстрее строится страница, но мне такой подход не нравится.
4. Поставил связку nginx+apache+mysql
Осталось правильно настроить эту связку. Например, можно через nginx отдавать сохраненный html всей страницы, а если его нет - отправлять запрос в php.
Ну и самое главное, что Вам уже сказали - вы оптимизировали генерацию страницы (да и то не полностью: где eaccelerator? где мемкеш? почему используются where/join? почему вообще используется mysql? =)))). А вот время загрузки страницы зависит от других параметров: размера страницы, количества и размера медиафайлов, количества и размера js и css и пр.
Oops! Google Chrome could not find 123-realty.ru
Хы-хы-хы, этим вы добились сокращения времени генерации страниц, но не их загрузки
именно, теперь можно занятся вторым пунктом
а с чего решили что join быстрее where? По сути join всегда тяжелее, так как является влложенным запросом
Зависит от кучи факторов (скажем id-ы в таблицах - индексы или нет? первичные или нет? и т.п.), но в общем случае JOIN предпочтительнее. у меня результат explain на join лучше
Лучше разбейте большие запросы на несколько мелких, собирайте результат в php и кешируйте. Часто помогает.
Немного не понятно, что именно кешируете. Я всегда кеширую данные, многие знакомые - блоки html. У них явно быстрее строится страница, но мне такой подход не нравится.
Осталось правильно настроить эту связку. Например, можно через nginx отдавать сохраненный html всей страницы, а если его нет - отправлять запрос в php.
Ну и самое главное, что Вам уже сказали - вы оптимизировали генерацию страницы (да и то не полностью: где eaccelerator? где мемкеш? почему используются where/join? почему вообще используется mysql? =)))). А вот время загрузки страницы зависит от других параметров: размера страницы, количества и размера медиафайлов, количества и размера js и css и пр.
Кеширую только результаты запросов к Mysql. Кеш простой serialize/unserialize но эффект замечательный
Oops! Google Chrome could not find 123-realty.ru
Сайт доступен
для тех кто не знает, еакселератор замедляет загрузку страниц☝
Некорректный заголовок топика, я оптимизировал генерацию страницы.
Теперь вопрос как оптимизировать загрузку страницы?
donriga, как Микеланджело - берешь страницу и убираешь все лишнее
Чтобы задавать вопросы, нужна статья на 10 000 знаков с картинками.
А так это уныло и всем пофигу, что вы там сделали со своим движком.