PHP.SU

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

Страниц (773): [1] 2 3 4 5 6 7 8 9 ... » В конец

> Найдено сообщений: 11594
Мелкий Отправлено: 20 Апреля, 2018 - 11:03:52 • Тема: Не корректно выводится время • Форум: CMS и фреймворки

Ответов: 2
Просмотров: 42
Видимо дефолтную TZ по пути кто-то трогает. Через date_default_timezone_set например.
Если хотите в какой-то конкретной tz быть - возьмите класс datetime и укажите объекту таймзону в явном виде.

А может ещё timestamp with timezone в базе аффектится своими настройками соединения. Таймзоны вещь такая, вопрос правильного времени весьма размыт.
Мелкий Отправлено: 18 Апреля, 2018 - 10:49:36 • Тема: Как проверить что email не отправился? • Форум: HTTP и PHP

Ответов: 6
Просмотров: 99
Doox911 пишет:
А подскажите по первому пункту. Где почитать? Чем пользоваться? А остальные пункты это настройка сервера? Для виртуального это надо к поставщику обращаться?

Пункт первый - это показанная вами проверка в начале темы.
Пункт второй - это настройка сервера
Пункт третий - логика сервера получателя.

Сквозь последние два - SPF, DKIM, blacklist'ы и прочий антиспам.

Будет ли отбивка mail delivery - есть варианты.
Мелкий Отправлено: 17 Апреля, 2018 - 20:23:16 • Тема: Как проверить что email не отправился? • Форум: HTTP и PHP

Ответов: 6
Просмотров: 99
Doox911 пишет:
Срабатывает код типо отправилось, на самом деле нет

На самом деле:
1) не передано MTA
2) MTA не доставил серверу адресата
3) сервер адресата не передал письмо пользователю
Выберите нужный.
PHP может проверить только первый пункт.
Мелкий Отправлено: 16 Апреля, 2018 - 14:59:27 • Тема: ошибка on line 3 • Форум: Вопросы новичков

Ответов: 4
Просмотров: 112
Значит у вас сильно устаревшая книга. 5.3.0 уже 9 лет почти.
Мелкий Отправлено: 10 Апреля, 2018 - 10:42:47 • Тема: Просьба помочь с вложенным запросом • Форум: SQL и Архитектура БД

Ответов: 2
Просмотров: 78
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT ... FROM t_tovars LEFT JOIN t_properties USING(tovar_id)
  2. WHERE property_value=10 OR t_properties.tovar_id IS NULL
Мелкий Отправлено: 03 Апреля, 2018 - 10:25:19 • Тема: htmlspecialchars не спасает • Форум: Вопросы новичков

Ответов: 2
Просмотров: 100
Вопроса в принципе не будет, если прочитать мануал к htmlspecialchars.
Цитата:
' (single quote) ' (for ENT_HTML401) or ' (for ENT_XML1, ENT_XHTML or ENT_HTML5), but only when ENT_QUOTES is set
Мелкий Отправлено: 01 Апреля, 2018 - 10:34:04 • Тема: расширенный поиск • Форум: Вопросы новичков

Ответов: 7
Просмотров: 220
Vladimir Kheifets пишет:
Вывод:
Ваше решение работает а четыре раза медленне моего

Внимательнее надо результаты сравнивать.
Если не придираться к самому измерению - то разница в 2,5 раза. Внимание на порядок величин.

Если придираться к измерению - единичное измерение будет сильно плавать. Необходимо повторять на значительном числе итераций.

И по существу - оба времени генерации SQL не имеют значения на фоне времени выполнения этого запроса, который в большинстве случаев даст гарантированный seqscan всей таблицы.
Мелкий Отправлено: 29 Марта, 2018 - 14:59:41 • Тема: Laravel миграции • Форум: CMS и фреймворки

Ответов: 6
Просмотров: 202
Вы очевидно неверно передаёте параметры, а ларавеловская консоль недостаточно проверяет параметры (наивно считает что разработчики иногда читают мануалы?)

https://laravel[dot]com/docs/5[dot]6/migrations
--create - это отдельный параметр.
Мелкий Отправлено: 29 Марта, 2018 - 11:28:39 • Тема: Как ускорить работу вебсайта • Форум: Программирование на PHP

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

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


Даже свой extension - это гарантированное требование иметь рутовый доступ к системе. Вмешательство в исходник - тем более. Плюс полностью не ясен смысл действия, т.к. во-первых существует штатный функционал (и потому в апстрим не примут гарантированно), и во-вторых потребность в ручном распиливании на разные диски есть только у уже больших проектов, где так называемых простых пользователей нет.
Мелкий Отправлено: 28 Марта, 2018 - 16:17:46 • Тема: Как ускорить работу вебсайта • Форум: Программирование на PHP

Ответов: 13
Просмотров: 321
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
Мелкий Отправлено: 28 Марта, 2018 - 13:40:45 • Тема: Как ускорить работу вебсайта • Форум: Программирование на PHP

Ответов: 13
Просмотров: 321
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 лет назад.
Сейчас нет проблем с получением информации. А для разработки СУБД сейчас вам критически не хватает базовой теории.
Мелкий Отправлено: 27 Марта, 2018 - 23:51:03 • Тема: Как ускорить работу вебсайта • Форум: Программирование на PHP

Ответов: 13
Просмотров: 321
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.
Мелкий Отправлено: 27 Марта, 2018 - 17:59:46 • Тема: Как ускорить работу вебсайта • Форум: Программирование на PHP

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

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

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

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

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

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

У меня разные базы, от сотен rps до десятков тысяч, от нескольких гигабайт до десятка террабайт, читающие интенсивно с дисков и не трогающие диски кроме как для записи wal и checkpoint'ов. Я DBA и у меня несколько сотен СУБД на поддержке. Я многого не знаю о базах данных, но и многое уже знаю.
Мелкий Отправлено: 26 Марта, 2018 - 21:31:03 • Тема: Долой backend! Все делаем на javascript в frontend. • Форум: JavaScript & VBScript

Ответов: 2
Просмотров: 178
Если вам не нравится заниматься backend'ом - то просто не занимайтесь. Людей влезающих в тот ад что последние сколько-то лет творится вместо фронтенда по прежнему не хватает.

lerneree пишет:
Фактически программист может даже не знать о серверной стороне, для него процессор оперативная память и диск сервера это всего лишь расширение браузера.
Сделать это совсем не трудно с помощью ajax.

Вас убьёт латентность сети.

А так - чем только странным люди не занимаются. Попробуйте сделать, получите интересный опыт.
Спойлер (Отобразить)
Мелкий Отправлено: 26 Марта, 2018 - 21:20:51 • Тема: Как ускорить работу вебсайта • Форум: Программирование на PHP

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

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

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

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

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

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

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

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

Страниц (773): [1] 2 3 4 5 6 7 8 9 ... » В конец
Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB