- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
3. Не нужно все перегонять в статику, особенно если сайт динамично изменяется.
Не соглашусь.
База хим. элементов по идее не должна содержать элементы которрые меняются часто,
ну там 1-2 элемента в год. Какая там динамика.
Ну а в целом неплохо было-бы посчитать нагрузку по числу запросов.
Фактически яндекс позволяет имитировать нагрузку создаваемую некоторым числом посетителей, и отбенчить сайт на предемет той нагрузки которую он выдержит.
Если число посетителей планируется в будущем не больше создаваемой нагрузки в пиковые моменты, то можно пытаться затюнить сайт, если явно больше, то
вперёд к статике.
Замечу, что статика может быть с SSI, или генеримая из какой-то базы в случае изменения в оной. Тоесть никто не предлагает отказаться от базы вообще.
Прелдагается отказаться от неё в при выдаче контента посетителю.
Если Вы всетаки решите, что основная причина в mysql - откажитесь от него. если объем информации не превышает 30-50М, в вашей ситации похоже так и есть, всю инфу прощк хранить в txt файлах или в варантах DBM (Perl) - работает быстро и не жрет рессурса.
Желание исопользовать связку php+mysql уже погубило многих. Связка такая, конечно, имеет иногда оправдание, но это не единсвенное решение, особенно когда используются CMS где апсолютно все в базах.
Если страницы мало обновляются (то бишь очень мало запросов UPDATE/INSERT, преобладают запросы SELECT), то конечно лучше один раз сгенерить все страницы с хтмл и сложить их в отдельную директорию, и вот оттуда уже скриптом (парсящим УРЛ запроса) выдавать посетителю сайта. Работать всё будет - быстрее некуда.
вообще хостинг, может, голову морочит еще...
вообще ИМХО хостинг самое главное, помню сидели мы на одном "хостинге" так там по приходу янедкса , гугла сразу мускул падал, причем падал напроч.... по 30 мин ремонтировали все.
У меня на чахлом PIV крутятся сайты с базами по 500000 записей и ничего, яндекс не валит. А есть клиент с сайтом из 100 записей, который грузит двойной ксеон вусмерть одним-двумя запросами, которые генерят страницу по 10 секунд.
Я к тому, что без детального анализа ваших скриптов и базы любой совет будет не более чем предположением.
Но статистически я скажу - скорее всего корявые запросы.
Если страницы мало обновляются (то бишь очень мало запросов UPDATE/INSERT, преобладают запросы SELECT), то конечно лучше один раз сгенерить все страницы с хтмл и сложить их в отдельную директорию, и вот оттуда уже скриптом (парсящим УРЛ запроса) выдавать посетителю сайта. Работать всё будет - быстрее некуда.
вот праздник хостеру будет, когда ТС последует вашему совету и начнет генерить 50000 страниц, и особенно при цчете что его скрипты грузят хостинг :D
Если Вы всетаки решите, что основная причина в mysql - откажитесь от него. если объем информации не превышает 30-50М, в вашей ситации похоже так и есть, всю инфу прощк хранить в txt файлах или в варантах DBM (Perl) - работает быстро и не жрет рессурса.
Желание исопользовать связку php+mysql уже погубило многих. Связка такая, конечно, имеет иногда оправдание, но это не единсвенное решение, особенно когда используются CMS где апсолютно все в базах.
я думаю, что смена "движка" - а переход с MySQl на текст или DBM - не более чем смена движка, вряд-ли что-то ускорит.
Обязательно:
1. HTTP заголовки выправить (кеширование, дата документа).
2. Сообщайте боту о перегрузке, до того как перегрузка наступила.
Дописываем в скрипт процедурку, которая после получения NN запросов с XX айпи за MM секунд выдаёт вместо страниц код ошибочки 503, например так:
print "Status: 503 Service Unavailable\nRetry-After: 61\nContent-Type: text/html\n\n";
print "<html><head><title>Не сканировать быстро!</title><meta http-equiv='content-type' content='text/html; charset=windows-1251'></head><body style='COLOR: black; FONT: 8pt/11pt verdana'><h1 style='COLOR: black; FONT: 13pt/15pt verdana'>Не сканируйте этот сайт так быстро.</h1>Вам требуется увеличить время между отправкой запросов к нашему серверу.<br><br><hr color='#C0C0C0' noshade width=400 align=left>Что бы получить запрашиваемую страницу, подождите 1 минуту<br>и нажмите кнопку "обновить".</body></html>";
Думаю, сканер Яндекс написан людьми которые внимательно читали документацию по протоколу HTTP, и следовательно он обязан учитывать код 503.
Дополнительно.
а) 50к записей/страниц, это не много.
б) Сообщите, за какое время у Вас отрабатывает скрипт при генерации 1 страницы (что бы иметь представление о Вашем "оптимизировано").
... и вот оттуда уже скриптом (парсящим УРЛ запроса) выдавать посетителю сайта. Работать всё будет - быстрее некуда.
А еще быстрее будет это делать Apache!☝
вот праздник хостеру будет, когда ТС последует вашему совету и начнет генерить 50000 страниц, и особенно при цчете что его скрипты грузят хостинг :D
Можно один раз сгенерить основную массу, раз не очень и меняется...
А потом - только изменения и дополнения. А меню, если меняется, запихать в INCLUDE.
Хостер будет в щастье!
ЗЫ. Не с ПХП начинался WEB... ;)
Можно один раз сгенерить основную массу, раз не очень и меняется...
А потом - только изменения и дополнения. А меню, если меняется, запихать в INCLUDE.
Хостер будет в щастье!
Спасибо за понимание :) примерно это я и имел в виду.
А сгенерить можно и на локальном компе, а потом залить один раз на сервак.
Приходит робот Яндекса и валит сайт.
Везет же людям 😂
На иные сайты робот месяц не ходит.