Владимирский центр культуры и поддержки творчества "Звенящие кедры России" Владимирский центр культуры и поддержки творчества "Звенящие кедры России"
 Помощь  • Правила  •  Поиск   •  Регистрация  •  Профиль  •  Войти и проверить личные сообщения  •  Вход
Рассылка RSS Нужен ли под домен anastasia.ru выделенный ф. сервер? Следующая тема | Предыдущая тема
Дополнительные настройки темы
Начать новую темуЭта тема закрыта, вы не можете писать ответы и редактировать сообщения.   Все сообщения темы   вывод темы на печать
Poll :: Нужен ли под домен anastasia.ru выделенный физический сервер?

- Да
85%
 85%  [ 24 ]
- Нет
3%
 3%  [ 1 ]
- Мне и того что есть хватает
10%
 10%  [ 3 ]
Всего проголосовало : 28   [Подробно]



АвторСообщение
Oleg_Stavros




Зарегистрирован: 02.10.2003
Сообщения: 78
Благодарили 2 раз/а


71157СообщениеДобавлено: Вс 12 Окт 2003, 22:50 | Ответить с цитатойВернуться к началу

Greg, я случайно наткнулся на статью по оптимизации, может она тебе чем-то поможет в твоем нелегком, но очень нужном для всех деле.

Автор Евгений В. Жданов
protoplex@mailru.com (protoplex@mailru.com?subject=От посетителя РМП
ProtoPlex)
http://protoplex.ru/ ('http://protoplex.ru/') Октябрь 12, 2003
[02:59]

Многие мои друзья и знакомые часто спрашивают меня о том, как устроен
мой сайт, сколько у меня таблиц в базе данных, как я храню данные и по
каким полям веду поиск. Я, конечно, не выдаю все свои государственные
тайны, но всегда понимаю причину таких вопросов и пытаюсь помочь людям
построить быструю и надежную базу данных - т.е. тщательно продумать
структуру БД таким образом, чтобы при увеличении нагрузки или объема
таблиц динамический веб-сайт не превратился в тормозное усмертие. А
ведь многие новички (веб-строители) даже не догадываются о том, что
крупные динамические сайты тормозят вовсе не из-за нагрузки скриптов
на процессор, а в основном из-за неоптимизированного или дохленького
MySQL-сервера. При этом во многом все зависит от того, как устроена
ваша база данных.

Итак, начнем ликбез. Сразу всем вопрос: что делает MySQL во время
записи в таблицы типа INSERT или UPDATE? Правильно - БЛОКИРУЕТ ТАБЛИЦЫ
и пишет в них данные. Скорость записи и поиска может быть достаточно
низкой, поэтому статус таблиц запрещает другим процессам считывать из
них данные до окончания операции записи или обновления и снятия
блокировки. При этом может получиться так, что во время записи
единственного поля в длинные таблицы, ваш MySQL-сервер надолго
заблокирует доступ к таблице остальным скриптам.

Например, вы создали таблицу новостей такого типа:

ID - номер, первичный ключ
TEMA - тема новости
MESS - сообщение, сама новость
VIEWS - количество просмотров

При каждом обращении к новостям, скрипт будет выводить саму новость, а
потом увеличивать поле VIEWS запросом UPDATE table 'NEWS' set
VIEWS=VIEWS+1 where id=ID. При этом количество апдейтов будет довольно
высоким. При высокой посещаемости веб-ресурса или при "нападении" на
сайт поискового робота (эти ребята страдают многопоточностью и могут
запросто повесить ваш сайт своими запросами) несколько одновременных
процессов станут пытаться сделать UPDATE и SELECT. При каждом UPDATE
таблица будет блокироваться (на это уходит время) и все остальные
процессы будут ждать завершения операции. А если таблица достаточно
большая? Например, несколько тысяч записей. Ежу понятно, что
построится очередь из нескольких десятков скриптов, ожидающих ответа
MySQL-сервера. Каждый будет жрать память и держать остальные процессы.
В итоге все у вас зависнет и переглючит. Выход: делать вместо одной
таблицы несколько. Советую разделять поля по типу их использования.
Одну таблицу - только для вывода и редких обновлений или вставок.
Другую - для частых обновлений, но редкого вывода. Например, значения
счетчика обращений держать отдельно в таблицу вида:

ID - номер, первичный ключ
VIEWS - количество просмотров

Сами новости лучше держать в другой таблице, где нет поля VIEWS. При
этом таблица с новостями будет тяжелой (много текста, полей,
индексов), а таблица COUNT (счетчик) будет очень легкой и быстрой.
Таблица NEWS будет кешироваться и выводиться очень быстро при любых
объемах, а таблица COUNT будет быстро обновляться из-за того, что она
очень легкая (всего два целочисленных поля). Разделение данных по
нескольким таблицам существенно ускоряет работу MySQL-сервера. Гораздо
быстрее работают несколько мелких запросов по каждой таблице, чем один
длинный запрос по одной или нескольким таблицам. Имейте это в виду,
чтобы спать спокойно.

Дальше - круче. Чтобы не блокировать лишний раз свои таблицы
используйте при вставках директиву DELAYED. Пример: INSERT DELAYED
into STAT (ID,IP,UTIME) values (null,$ip,NOW()). Он позволяет серверу
ответвлять поток в режиме ожидания, а саму вставку производить тогда,
когда сервер освободится от других запросов или поступит следующий
аналогичный INSERT DELAYED. Обычно отложенный метод подходит для любых
операций с кумулятивными таблицами (когда в основном идут INSERTы, а
данные копятся, а не модифицируются), при которых не особо важно когда
именно подействуют изменения - мгновенно или через несколько секунд,
минут. Например, если хотите собирать IPадреса своих посетителей,
УРЛы, по которым они ходят или страницы, откуда пришли, время. При
добавлении с задержкой скрипт отработает почти мгновенно, еще до
выполнения операции.

Операция UPDATE идет в три этапа: поиск того, что будете менять, затем
запись данных, обновление индексов. При этом, чем больше таблица, тем
дольше поиск. Если есть индексы, то операция кешируется и выполняется
достаточно быстро. Но сам процесс очень емкий. И только дурак не
догонит, что большая таблица со множеством индексов и записей, будет
тормозить при UPDATE. INSERT же выполняется одним залпом, очень
быстро. Поэтому обычно используют аддитивные записи (вставками INSERT)
во временные таблицы, потом блокируют основные талицы, суммируют
обновления, и плюют их в основную таблицу. Получается, что в основном,
главные таблицы работают только в режиме вывода, а обновления идут
гораздо реже и быстрее. Например, можно копить данные о загрузках
новостей во временной таблице, а по крону или иным образом обновлять
счетчик каждые 10 минут (или реже). Это ускорит работу сервера.

При запросах SELECT * FROM таблица скрипт получит все поля данной
таблицы. А нужно ли это? Использование * ведет к лишнему расходу
ресурсов. Гораздо эффективнее использовать точные названия полей,
которые нужны скрипту. Например: SELECT id,name FROM таблица. При
таком запросе передача займет меньше времени и понадобится меньше
ресурсов. Старайтесь ограничивать вывод при помощи директивы LIMIT.
Это также ускоряет вывод.

Поиск по БД идет быстрее если вместо LIKE '%слово%', ставить 'слово%'.
Операции с шаблонами регулярных выражений кешируются только в том
случае, если в начале отсутствует символ %. Поэтому при построении
поисковых запросов с LIKE избегайте начинающих символов %.

При построении таблиц для наиболее используемых полей (при поиске,
сортировке и т.д.) обязательно создавайте индексы. Без индексов
таблицы будут сильно тормозить. Индексы служат для кеширования и
позволяют существенно ускорить вывод данных из таблиц. При этом
таблицы будут занимать больше места на диске и в памяти. Но это в наше
время не проблема.

Используйте надлежащий тип полей для своих записей. Тип TINYINT
занимает 1 байт - самый быстрый. Таблицы с MEDIUMINT быстрее таблиц с
INT. Если ставить полям свойство NOT NULL, то в целом их работа будет
быстрее. VARCHAR медленее CHAR, поэтому таблицы переменной длины (где
есть тип VARCHAR или TEXT) занимают меньше дискового пространства, но
работают медленнее.

По своему опыту скажу, что для большинства сайтов подходят изложенные
советы по работе с MySQL. Чтобы еще больше ускорить свой сервер,
советую частоиспользуемые операции проводить по крону выделенными
процессами и писать данные в различные файлы. Например, раз в 20 минут
запускать скрипт, который будет создавать файл с новостями. Или
например, генерить файл с новостями при их добавлениях или
обновлениях. Таким образом, вы экономите на каждом обращении к БД.
Интерактивность при этом не теряется, а производительность
увеличивается во много раз. Особенно, повторяю, при высокой
посещаемости ресурса. Старайтесь отделить интерактивные операции от
фоновых. Например, на ПротоПлексе работает один интерактивный движок,
но в фоне по заданиям трудятся с десяток различных роботов, которые
генерируют часто вызываемые страницы, рассылают письма и т.д. Крупный
сайт - это не только то, что вы видите, но и бек-енд (обратная
сторона). В фоновом режиме можно быстро и эффективно готовить контент,
освобождая основной движок от лишней работы.

В общем, основы должны быть всем понятны. Дробите все на мелочи, будь
то запросы, таблицы или операции. Структура БД должна быть такой,
чтобы не выполнялось ничего лишнего. Регулярно проводите OPTIMIZE на
таблицах с переменной длиной, особенно, если в них идут удаления
записей. Тестируйте свои запросы на скорость, упрощайте их. Ну а я уже
устал это писать Smile Если будут вопросы, пишите, отвечу.
_________________________________________________________________

Вся информация, содержащаяся в данной рассылке, является
интеллектуальной собственностью своих законных авторов. При
перепечатке материалов из рассылки для соблюдения закона об авторских
правах необходимо указывать имена и все ссылки авторов. Также
необходимо ставить видимую ссылку на Российский мультипортал ProtoPlex
protoplex.ru> (HTTP://protoplex.ru)

Copyright ї 2000-2003 Студия Евгения Жданова
(HTTP://design.protoplex.ru/)

_________________
С уважением, Олег.
-
Посмотреть профильОтправить личное сообщение
greg




Зарегистрирован: 17.08.2002
Сообщения: 731
Благодарили 63 раз/а
Населённый пункт: Владимир

71503СообщениеДобавлено: Ср 15 Окт 2003, 17:40 | Ответить с цитатойВернуться к началу

Сервер скорее всего будет, по времени ближе к декабрю. Точно время не скажу я ещё сам не знаю Smile

_________________
С уважением, Григорий.
Посмотреть профильОтправить личное сообщениеПосетить сайт автора
ogmion

Ищу половинку :)




Зарегистрирован: 13.04.2003
Сообщения: 420
Благодарили 111 раз/а
Населённый пункт: Воткинск

81305СообщениеДобавлено: Сб 20 Дек 2003, 4:18 | Ответить с цитатойВернуться к началу

хммм... Sad
Пациент скорее всё же жив, нежели мёртв.... я не причем
Делали пересадку "движка"? сюрприз
Посмотреть профильОтправить личное сообщение
zayatsapsny



Возраст: 68
Зарегистрирован: 28.12.2004
Сообщения: 523
Благодарили 35 раз/а
Населённый пункт: Россия,Сочи

605857СообщениеДобавлено: Пн 17 Мар 2008, 1:39 | Ответить с цитатойВернуться к началу

greg, Сервер нужен как воздух.Деньги да понимаю.Если они есть,конечно нужно,просто необходимо,если мы хотим изменить себя и мир,а иначе как?

Да,просьба не по теме,удоляйте те вопросы и ответы которые будут не по теме.


Где главная страниц,не могу найти?

_________________
Ты бесконечен! Вечен ты!
Анастасия
Посмотреть профильОтправить личное сообщениеОтправить e-mailAIM AddressMSN MessengerICQ Number
love_harbinger




Зарегистрирован: 29.03.2006
Сообщения: 7388
Благодарили 18 раз/а
Населённый пункт: Kursk - Greece

605861СообщениеДобавлено: Пн 17 Мар 2008, 1:53 | Ответить с цитатойВернуться к началу

zayatsapsny, этой теме возраст четыре с половиной года. Актуальная ли она теперь?

Насчет главной страницы: www.anastasia.ru

_________________
...От южных морей до полярного края...
Посмотреть профильОтправить личное сообщениеОтправить e-mailICQ Number
Показать сообщения:      
Начать новую темуЭта тема закрыта, вы не можете писать ответы и редактировать сообщения.   Все сообщения темы   вывод темы на печать


 Перейти:   



Следующая тема
Предыдущая тема
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете вкладывать файлы
Вы можете скачивать файлы



Журнал модерирования


© 2002-2018 Все права принадлежат Anastasia.ru!
Все материалы, публикуемые на этом сайте, могут быть использованы на усмотрение Фонда "Анастасия", в том числе, и в выпусках Альманаха. Если Вы используете материалы с нашего сайта, то ссылка на нас обязательна. За информацию, размещённую на сайте пользователями, администрация Фонда "Анастасия" ответственности не несёт!


Powered by рhрВВ © 2001, 2002 рhрВВ Group :: FI Theme :: Часовой пояс: GMT + 4
Русская поддержка phpBB