- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Пишу статью на тему уменьшения нагрузки сайта на сервер, где соберу воедино все свои размышления на этот счёт.
Предлагаю и Вам принять небольшое участие в сборе этой инфы, принципов и приёмов по уменьшению нагрузки.
Есть сомнение вот в этом:
+ PostregreSQL даёт меньшую нагрузку при одинаковых запросах, чем MySQL
это верно, нет?
Вот что ещё у меня получается (краткие выкладки). Для того, чтобы уменьшить нагрузку нужно:
+ Оптимизировать скрипты (выявить участки кода, которые используют "впустую" процессорное время);
(Выявить и убрать ненужные функции/участки из кода);
+ Оптимизировать запросы SQL (MySQL, PostregreSQL, и других БД):
(Уменьшить кол-во запросов к MySQL и обращаться к этому серверу только по необходимости);
+ Использование принудительного кэширования там, где это возможно;
+ Использование mod_rewrite и окончания .html (чтобы браузеры кэшировали самостоятельно);
+ Все большие базы данных с txt файлов перенести на MySQL;
Подскажите пожалуйста что-нибудь ещё, что я ещё забыл упомянуть..?
Тема обширная и полезная. Народ, не стойте в стороне - принимайте участие в дискуссии!
ИМХО баян очередной пишите :)
Большие - это насколько большие?
Они итак кешируют, без всяких .html
(Выявить и убрать ненужные функции/участки из кода);
баян
опять баян
это верно, нет?
мускуль шустрее на мелких запросах, на более-менее серьезных он здесь не конкурент
от себя (из практики):
написать правильный robots.txt
включить фильтры ботов по user-agent
рекомендую начать Вашу статью именно с этих пунктов, а уж потом оптимизировать код и прочее
На dedic.ru есть достаточно материала на эту тему
Ерунда какая-то, а не советы.
Оптимизировать скрипты (выявить участки кода, которые используют "впустую" процессорное время);
(Выявить и убрать ненужные функции/участки из кода);
Ага. Берете, значит, проект с мегабайтом кода и давай оптимизировать скрипты.
Не забудьте еще про мир во всем мире написать - столь же реально.
Оптимизировать запросы SQL (MySQL, PostregreSQL, и других БД):
(Уменьшить кол-во запросов к MySQL и обращаться к этому серверу только по необходимости);
Аналогично бесполезный совет.
Все большие базы данных с txt файлов перенести на MySQL;
Нафига?
Вообще, извините, вы сколько проектов, реально создающих нагрузку на сервер, имеете?
А все эти "советы" можно заменить одним - выбросьте старый код и напишите новый заново. Идеальная установка для программиста-двоечника.
FixGuitar, если вы программист, то пишите сразу нормальные скрипты, если администратор - настраивайте сервер.
Что касается MySQL и PostregreSQL, то вообще система с MySQL работает быстрее (в целом), но учитывая ее популярность на хостингах, можно предположить, что использование PostregreSQL даст выигрыш в производительности, в связи с менее загруженным сервером баз данных.
Пишу статью на тему уменьшения нагрузки сайта на сервер, где соберу воедино все свои размышления на этот счёт.
Предлагаю и Вам принять небольшое участие в сборе этой инфы, принципов и приёмов по уменьшению нагрузки.
Как правило, в системе два узких места - количество одновременных пользователей и скорость выполнения запросов на базе данных. Первое решается nginx, второе кешированием данных. В подавляющем большинстве случаев этих очень дешёвых методов хватает для значительного снижения нагрузки. Вот и вся статья.
FixGuitar, если вы программист, то пишите сразу нормальные скрипты, если администратор - настраивайте сервер.
Сразу нормальные скрипты написать нельзя (теоретически). Всегда есть возможность что-то улучшить. Да и все относительно , оди операторы быстрее для маленьих данных, например при выборке из бд, а другие при больших .. (говорю на примерах пхп4)
А по теме, если грузит сильно, Уменьшайте кол-во запросов, делайте кеширование. статические странички ...
Спасибо за советы!
Ерунда какая-то, а не советы.
Это был всего лишь небольшой старт-ап :)
Ага. Берете, значит, проект с мегабайтом кода и давай оптимизировать скрипты.
Не забудьте еще про мир во всем мире написать - столь же реально.
Ну а куда же деваться. При мегабайтах кода, возможно, проще переписать некоторые "грузные" участки/скрипты, чем переписать с нуля, как Вы предлагаете в своём сообщении.
По переводу баз данных в тхт на MySQL - парсинг больших файлов занимает много времени и даёт большую нагрузку.
"большие тхт", насколько большие?
Тут, по-моему, вообще лучше не иметь дело с текстовыми файлами в качестве баз данных, если формат их слишком простой или обычный, тут уже как Вам проще это назвать.
Понятное дело, что конечном счёте MySQL это тоже файлы, но я сейчас не об этом. MySQL это специализированный сервер баз данных, если его оптимизировать корректно (верно устанавливать основные/др. ключи, проводить индексацию), то здесь несомненно будет выигрыш в скорости и производительности, нежели у обычных текстовых файлов, в которых этого всего вообще нету.
Если база данных находится в "простом" (отсутствие спец. структуры, напр.) формате текстового файла - лучше перевести её на MySQL.
Если писать спец. формат базы данных, то это уже другой, весьма не простой вопрос. И не отрицаю, что вполне приемлемый. Единственное не стоит забывать о том, что над MySQL тоже не дураки работают. Это годами отработанное средство хранения баз данных. Не так-то просто написать что-то лучше. Тем более малой группой разработчиков :)
А все эти "советы" можно заменить одним - выбросьте старый код и напишите новый заново. Идеальная установка для программиста-двоечника.
Ну зачем же сразу выбрасывать его. Возможно целесообразно переписать только некоторые участки/скрипты, а не весь проект.
Хотя возможно Вы сейчас говорите как раз о частях, а не о всём коде. Тогда прошу прощения.
Kpd,
Я-то программист :) Но статью пишу не только для программистов, а в качестве обзора для владельцев проектов - откуда могут исходить подобные нагрузки. Вовсе не обязательно, что её читать будут и интересна она будет только программистам.
По поводу Вашего сообщения. "сразу нормальные скрипты" слишком обширное и сложное понятие. :)
Нередко цели скрипта меняются, ещё что-то, всякие ситуации бывают.
Изначально идеальный или "нормальный" скрипт никогда не напишешь. Всегда можно что-то улучшить по ходу процесса создания скрипта. Всегда. Код постоянно улучшается. Рефакторинг спасёт человечество :)
Velior,
Спасибо. Мысль интересная.
Слава Шевцов,
Спасибо большое. Идею кэширования запросов я действительно упустил.
Miracle,
Полностью согласен. Не прочёл изначально Ваше сообщение, поэтому чуть выше написал почти всё тоже самое про улучшение скриптов :)
Спасибо большое за участие в теме. Надеюсь она хотя бы кому-то поможет, тут собрана действительно полезная информация!
Ставим sql кластер, ставим веб ферму + между ними юзаем memcache
Добавляем тазики по мере роста. И все дела.