PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (1): [1]   

> Описание: Как ускорить работу вебсайта
lerneree
Отправлено: 26 Марта, 2018 - 20:09:49
Post Id


Новичок


Покинул форум
Сообщений всего: 10
Дата рег-ции: Март 2018  


Помог: 0 раз(а)




Основнок время при работе вебсайта это запрос к базе данный.
Бак работает жесткий диск:
http://pc-information-guide[dot]ru/z[dot][dot][dot]pyutera-hdd[dot]html
Кратко: на общем валу насажено несколько дисков, магнитные дорожки,
каждого находятся друг над другом и образуют так называемый цилиндр.
Есть коромысло с несколькими магнитными головками, по одной на каждый диск. Коромысло движется,
устанавливается на необходимый цилиндр и производит запись/чтение. Движется оно шустро, но конечно это
занимает значительное по компьютерным понятиям время.
Получается что когда коромыслр установлено на некоторый цилиндр оно
может очень быстро считывать или записывать инфлрмацию. А вот если при выполнении sql запроса требуется
обращение к таблицам находящимся на разных цилиндрах, то коромыслу приходится перемещаться и время выполнения
запроса резко увеличивается, иногда становится неприемлимым. Например для профиля пользователя надо по
имеющемуся ключам выбрать наименование страны, региона, города, улицы. Это потребует обращения к таблице с
профилем и еще к четырем.
Может быть катастрофа, если таблицы находятся на разных цилиндрах. Кеширование помогает но не всегда.
Твердотельные диски не имеют этой проблемы.
Здесь Вы можете ознакомиться с результатами испытаний и сравненее hdd с ssd
https://m[dot]geektimes[dot]ru/post/276052/
Разница в скорости десятки раз
А чтобы зло пресечь собрать бы hdd да сжечь! Но hdd память сильно дешевле, без них не обойтись. Так что
проблему надо решать, основные методы:
- оптимизировать расположение таблиц на диске. Для каждой реально работающей программы есть распределение
вероятностей запросов. Можно оптимально расположить таблицы минимизируя среднее время доступа или максимальное
время доступа. Это может сделать программист или же программа. Но я такой программы не смог найти. Кто знает
подскажите, пожалуйста.
- использовать два или больше дисков, также оптимизируя расположение таблиц. Например один из дисков может быть
ssd и на нем расположить маленькие таблицы.
- использовать оперативную память, она даже быстрее чем sdd, а уж если использовать кеш память то будет совсем
быстро. Для этого годятся журналируемые хранилища например
redis , memcached. Поскольку большинство сайтов работает на хостингах и виртуальных серверах без сисадмина, было бы
полезно сделать журналируемое хранилмще не требующее устпновки, на базе cron.
Беда в том что самая популярная субд mysql не позволяет размещать таблицы на разных дисках и тем
более не использует журналируемые хранилише. Может быть есть расширения для mysql позволяющие делать это ,
но я таких найти не сумел. Кто знает подскажите, пожалуйста.
Предлагаю основать open source проект и разработать систему для оптимизации дисковой памяти.
 
 Top
Мелкий Супермодератор
Отправлено: 26 Марта, 2018 - 21:20:51
Post Id



Активный участник


Покинул форум
Сообщений всего: 11651
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 578 раз(а)




lerneree пишет:
Основнок время при работе вебсайта это запрос к базе данный.

Бездоказательное утверждение.
Доказательством будет результат профилирования конкретной страницы. Но и доказывать будет конкретную страницу только.

lerneree пишет:
Для этого годятся журналируемые хранилища например
redis , memcached

Вы не понимаете значение слова "журналируемый"
memcached нежурналируемая система.
redis - зависит от настроек. Может быть нежурналируемым тоже.

lerneree пишет:
Беда в том что самая популярная субд mysql не позволяет размещать таблицы на разных дисках и тем более не использует журналируемые хранилише.

Ошибаетесь в обоих утверждениях.
Ещё как журналируемая, иногда дважды журналируемая, И на разные физические диски разносить её можно. Даже не прибегая к помощи блочного уровня ОС.

Прочтение пары статей про lowlevel работу механики HDD вас не приблизило к вопросу производительности СУБД, которым уже не одно десятилетие исследований и собранных граблей. Читайте дальше, и желательно что-нибудь потяжелее, Transactional Information Systems авторства Gerhard Weikum и Gottfried Vossen, например.
Впрочем, начните с классической книги high performance mysql.

Про io scheduler'ы и page cache вы явно ещё не слышали - тоже почитайте.


-----
PostgreSQL DBA
 
 Top
armancho7777777 Супермодератор
Отправлено: 27 Марта, 2018 - 07:01:56
Post Id



Активный участник


Покинул форум
Сообщений всего: 4658
Дата рег-ции: Февр. 2011  
Откуда: Иркутск, Россия


Помог: 214 раз(а)




Мелкий Круто


-----
Болтовня ничего не стоит. Покажите мне код.
-Linus Torvalds
 
 Top
lerneree
Отправлено: 27 Марта, 2018 - 14:32:54
Post Id


Новичок


Покинул форум
Сообщений всего: 10
Дата рег-ции: Март 2018  


Помог: 0 раз(а)




1 конечно с каждым сайтом надо разбираться конкрентно. и все таки если компилировать php
и не использовать неэффективных кострукций то тормозит hdd
2 ваше мнение конкретно-согласны вы с тем что физичекское размещение таблиц имеет большое значение?
3 я программирую 42 года тогда диски были совчем меделлные.
однажды меня попросили учкорить программу которая работала сутки. у меня она работала 20 мин
 
 Top
Vladimir Kheifets
Отправлено: 27 Марта, 2018 - 17:12:53
Post Id



Частый гость


Покинул форум
Сообщений всего: 196
Дата рег-ции: Март 2017  
Откуда: Германия, Бавария


Помог: 5 раз(а)




lerneree пишет:
1 конечно с каждым сайтом надо разбираться конкрентно. и все таки если компилировать php
и не использовать неэффективных кострукций то тормозит hdd
2 ваше мнение конкретно-согласны вы с тем что физичекское размещение таблиц имеет большое значение?
3 я программирую 42 года тогда диски были совчем меделлные.
однажды меня попросили учкорить программу которая работала сутки. у меня она работала 20 мин

Добрый день!
Согласен с Вами, что с каждым сайтом нужно разбираться и лучше не использовать в программировании неэффективные конструкции.
Относительно hdd, ssd, таблиц находящихся на разных цилиндрах, коромысла, которому приходится перемещаться...
Возможно, Вы правы, но к сожалению, даже самые замечательные идеи не всегда удаётся реализовать, потому,
что наши желания не всегда совпадают с нашими возможностями.
Специфика Веб-проектов состоит в том, что часто системы разрабатываются удалённо на серверах, на системную и техническую конфигурацию,
которых разработчики ПО влиять не могут.
Удачи!

(Отредактировано автором: 27 Марта, 2018 - 17:14:15)

 
 Top
Мелкий Супермодератор
Отправлено: 27 Марта, 2018 - 17:59:46
Post Id



Активный участник


Покинул форум
Сообщений всего: 11651
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 578 раз(а)




lerneree пишет:
если компилировать php
и не использовать неэффективных кострукций то тормозит hdd

Зависит от. Нет никаких проблем упираться в CPU или сеть, даже на медленных дисках. Даже загруженная СУБД может на медленных дисках работать и не являться узким местом системы. Просто бизнесу часто дешевле поставить SSD, чем тюнить проект под механику, да и в эксплуатации надёжнее и проще. Сервер приложения же упереть в io надо очень постараться.
К слову, упираться в производительность SSD тоже не так уж сложно.

lerneree пишет:
согласны вы с тем что физичекское размещение таблиц имеет большое значение?

Зависит от.
Некоторые workload получат преимущество от кластеризации, некоторые - не заметят, некоторым станет только хуже.
В общем случае нет, не имеет значения. Потому что локальность одних данных к другим на диске будет хороша для одних запросов и категорически не будет подходить для других запросов. Хорошо же работать база будет когда горячие данные размещены в её буферной памяти (лучше всего в памяти локальной NUMA, и хуже - если весь потребный буфер оказался в памяти remote NUMA) - это касается как механики, так и ssd.
Впрочем, что это я про NUMA, если по первому сообщению очевидно, что вы не знаете про наличие родного буфера в памяти у всех СУБД для хранения горячих данных.

lerneree пишет:
я программирую 42 года тогда диски были совчем меделлные.

Знаете, не впечатляет. У меня в разработке всего в 4 раза меньше стаж и то что вы при этом не знаете даже про page cache совершенно не впечатляет.

У меня разные базы, от сотен rps до десятков тысяч, от нескольких гигабайт до десятка террабайт, читающие интенсивно с дисков и не трогающие диски кроме как для записи wal и checkpoint'ов. Я DBA и у меня несколько сотен СУБД на поддержке. Я многого не знаю о базах данных, но и многое уже знаю.


-----
PostgreSQL DBA
 
 Top
lerneree
Отправлено: 27 Марта, 2018 - 22:51:50
Post Id


Новичок


Покинул форум
Сообщений всего: 10
Дата рег-ции: Март 2018  


Помог: 0 раз(а)




1 я не рассматриваю крупные бизнесы хочу сделать систему для массовго пользователя
предельно простую в использовании
2 да это сложно
3 на других форумах получил зорошие советы. надеюсь и на вас.
пока рассматриваю вопрос приложения для mysql которое помогало бы распределять таблицы по дискам в том числе и в in memory хранилищах
(Добавление)
Специфика Веб-проектов состоит в том, что часто системы разрабатываются удалённо на серверах, на системную и техническую конфигурацию,
которых разработчики ПО влиять не могут.

вот это точно. так я и хочу сделать чтоб влиять не надо было. идеально вообще ничего не устанавливать сделать хранилище в виде скерипта в cron с поддержеой sql.
вот redis и memchashed популярны но почему они от sql отказались?

если вернуться к коду то в вордпрес код хорощий а тормозит жутко. и масса плагинов для его ускорения
 
 Top
Мелкий Супермодератор
Отправлено: 27 Марта, 2018 - 23:51:03
Post Id



Активный участник


Покинул форум
Сообщений всего: 11651
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 578 раз(а)




lerneree пишет:
mysql которое помогало бы распределять таблицы по дискам в том числе и в in memory хранилищах

Уже встроено непосредственно в mysql. Давно. Memory storage engine кажется там был уже чуть ли не всегда.
А диски - если у вас нет возможности влиять на среду - у вас нет возможности влиять на диски. То есть банально нет ни прав крутить эти гайки ни даже необходимости в них. При распиливании базы по дискам надо чётко представлять какие диски есть, чем заняты и зачем мы их распиливаем вручную вместо одного raid10.

lerneree пишет:
вот redis и memchashed популярны но почему они от sql отказались?

Попробуйте реализовать грамматику хотя бы sql92, которую едва осилили в mysql.
Затем сравните с простейшим текстовым протоколом редиса. Почему? Потому что редису это не нужно. Он прост и он не ACID. Это сознательное архитектурное решение. С сознательными последствиями для данных. Аналогично мемкеш, хотя его протокол я не помню.
Не упоминаю Тьюринг-полный sql99 с рекурсивными CTE, которые наконец будут лишь в mysql 8.0.

И реализовать грамматику - это самая маленькая из бед. Куда интереснее вопрос с каждой из 4 букв аббревиатуры ACID. Фундаментальный труд по этой теме я уже указал.
Не исключаю, что в результате вы получите просто что-то напоминающее sqlite, которая давно является дефолтным расширением php.


-----
PostgreSQL DBA
 
 Top
lerneree
Отправлено: 28 Марта, 2018 - 12:26:46
Post Id


Новичок


Покинул форум
Сообщений всего: 10
Дата рег-ции: Март 2018  


Помог: 0 раз(а)




спасибо еще раз хочу уточнить

1 есть ли такое на mysql
создается файл где для каждой таблицы указывается ее физическое расположение (диск in memory)
mysql каждую пишет куда надо
2 sql lite можно ли с его помощью сделать in memory хранилище.
я понимаю что надо периодически сохранять всю бд на диск и писать логи ввода и изменения записй. так?
3 сдышали чтото о in memory хранилище на базе cron не требующую установки на сервер c поддержкой минимального sql
========
в общем хотелось бы сделать массовую систему для чайников вроде меня чтоб пользовались уже знакомыми средствами и с минимальными установками
 
 Top
Мелкий Супермодератор
Отправлено: 28 Марта, 2018 - 13:40:45
Post Id



Активный участник


Покинул форум
Сообщений всего: 11651
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 578 раз(а)




Mysql можно сказать, в какое место файловой системы размещать таблицу, в какое - индексы (в том числе для каждой таблицы отдельно). Зависит от storage engine и некоторых ещё настроек и не волнуйтесь, на шаредах у вас этих настроек нет. Как и вообще доступа в ФС базы.
Таблица гарантированно в памяти - memory storage engine, который я уже упоминал. Разумеется есть свои ограничения.
Горячие данные в памяти - ворох своих настроек, к которым у вас доступа опять же не будет. И они весьма не случайно именно настройки, а не автоматика.

lerneree пишет:
sql lite можно ли с его помощью сделать in memory хранилище.

Да и нет.
Можно что угодно разместить в памяти - tmpfs штука так же весьма и весьма старая. Необходимо понимать что это и к чему приведёт (даже если вдруг на шареде окажутся на неё права).
page cache удержит горячие данные в памяти сам по себе.

lerneree пишет:
я понимаю что надо периодически сохранять всю бд на диск и писать логи ввода и изменения записй. так?

Читайте литературу.
Есть разные подходы к обеспечению заданного уровня durability.
В основном используется персистентная копия, журнал изменений страниц и чекпойнты.

lerneree пишет:
in memory хранилище на базе cron

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

Цитата:
в общем хотелось бы сделать массовую систему для чайников вроде меня чтоб пользовались уже знакомыми средствами и с минимальными установками

Продолжайте использовать mysql. Прочтите high performance mysql и используйте её адекватно. Это шикарная книга по использованию mysql.
Повторюсь:
Мелкий пишет:
Прочтение пары статей про lowlevel работу механики HDD вас не приблизило к вопросу производительности СУБД

Вы очень далеко не первый, кому пришло в голову, что RAM быстрее HDD. Изучите для начала пропущенные вами 40 лет теории и практики. Конец 70-х получились? Маловато вышло. ACID сформулированы уже почти 40 лет назад.
Сейчас нет проблем с получением информации. А для разработки СУБД сейчас вам критически не хватает базовой теории.


-----
PostgreSQL DBA
 
 Top
lerneree
Отправлено: 28 Марта, 2018 - 15:59:50
Post Id


Новичок


Покинул форум
Сообщений всего: 10
Дата рег-ции: Март 2018  


Помог: 0 раз(а)




Читайте литературу.
Есть разные подходы к обеспечению заданного уровня durability.
В основном используется персистентная копия, журнал изменений страниц и чекпойнты.

дайте пжл ссылку на литературу. не нашел

inmemory база - долговременный процесс-демон.
крон сюда можно приплести разве только как супервизор, что никак не может быть в основе
да с кроном похоже на извращение. но вроде если повесить скрипт в крон должно работать.
вы понимаете чего я хочу - минимально трогать сервер. пользователи это не любят.
а крон есть и на обычном хостинге
 
 Top
Мелкий Супермодератор
Отправлено: 28 Марта, 2018 - 16:17:46
Post Id



Активный участник


Покинул форум
Сообщений всего: 11651
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 578 раз(а)




lerneree пишет:
вы понимаете чего я хочу

Нет, вообще не понимаю.
По этой теме впечатление, что хотите написать свою СУБД, заведомо ограниченную в ресурсах и потому медлительную, игнорируя при этом уже существующий sqlite. Вероятно из-за полного непонимания поставленных вами же самим перед собой ограничений для разрабатываемой базы.
По теме sqlru складывается впечатление, что вы хотите что-то прикрутить к mysql, даже близко не представляя, как работает современная СУБД и mysql в частности.

lerneree пишет:
дайте пжл ссылку на литературу. не нашел

https://www[dot]amazon[dot]com/Transacti[dot][dot][dot]cy/dp/1558605088
http://shop[dot]oreilly[dot]com/product/0636920022343[dot]do


-----
PostgreSQL DBA
 
 Top
lerneree
Отправлено: 29 Марта, 2018 - 11:05:15
Post Id


Новичок


Покинул форум
Сообщений всего: 10
Дата рег-ции: Март 2018  


Помог: 0 раз(а)




спасибо за ссылки. sqllite я не игнорирую а точно использую сделаю на нем хранилище
и добавлю еще json db
для mysql сделаю возможность размещать таблицы на разных дисках придетмя хардкодить
попробую чтото с cron хотя похоже это маразм
 
 Top
Мелкий Супермодератор
Отправлено: 29 Марта, 2018 - 11:28:39
Post Id



Активный участник


Покинул форум
Сообщений всего: 11651
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 578 раз(а)




lerneree пишет:
для mysql сделаю возможность размещать таблицы на разных дисках придетмя хардкодить

Или вы полностью не понимаете, что собираетесь делать или заведомо противоречите декларируемым целям:
lerneree пишет:
минимально трогать сервер


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


-----
PostgreSQL DBA
 
 Top
Страниц (1): [1]
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Программирование на PHP »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB