mysql_connect VS mysql_pconnect [закрытый]
Я уже нашел решение, и оно было дано из @zak:
var fromDate = $('#exit_end_document').val();
fromDate = new Date(fromDate);
toDate = new Date();
var weekendDays = 0;
dayMilliseconds = 1000 * 60 * 60 * 24;
date1 = fromDate;
date2 = toDate;
while (date1 <= date2) {
var day = date1.getDay();
if (day == 0 || day == 6) {
weekendDays++;
}
date1 = new Date(+date1 + dayMilliseconds);
}
alert(weekendDays);
3 ответа
Постоянные соединения должны быть ненужными для MySQL. В других базах данных (таких как Oracle), устанавливая связь является дорогим и трудоемким, поэтому если можно снова использовать соединение, это - большая победа. Но те бренды базы данных предлагают организацию пула подключений, которая решает проблему лучшим способом.
Устанавливание связи с базой данных MySQL быстро по сравнению с теми другими брендами, так использование постоянных соединений приносит пропорционально меньше пользы для MySQL, чем это было бы для другого бренда базы данных.
Постоянные соединения имеют оборотную сторону также. Сервер базы данных выделяет ресурсы каждому соединению, необходимы ли соединения или нет. Таким образом, Вы видите много потраченных впустую ресурсов ни для какой цели, если соединения неактивны. Я не знаю, достигнете ли Вы 10 000 неактивных соединений, но даже несколько сотен являются дорогостоящими.
Соединения имеют состояние, и было бы неуместно для запроса PHP "наследовать" информацию от сессии, ранее используемой другим запросом PHP. Например, временные таблицы и пользовательские переменные обычно очищаются, поскольку соединение закрывается, но не при использовании постоянных соединений. Аналогично основанные на сессии настройки как набор символов и сопоставление. Кроме того, LAST_INSERT_ID() сообщил бы об идентификаторе, в последний раз сгенерированном во время сессии - даже если бы это было во время предшествующего запроса PHP.
MySQL For, по крайней мере, оборотная сторона постоянных соединений, вероятно, перевешивает их преимущества. И существуют другие, лучшие методы для достижения высокой масштабируемости.
<час>март 2014 Обновления:
скорость Подключения mysql была всегда низкой по сравнению с другими брендами RDBMS, но это становится еще лучше.
Видят http://mysqlserverteam.com/improving-connectdisconnect-performance/
MySQL 5.6 In, мы начали работать над оптимизацией подключений обработки кода и разъединений. И эта работа ускорилась в MySQL 5.7. В этом сообщении в блоге я сначала покажу результаты, которых мы достигли и затем описываем то, что мы сделали для получения их.
Read блог для получения дополнительной информации и сравнений скорости.
В основном необходимо сбалансировать стоимость создания соединений по сравнению с хранением соединений. Даже при том, что MySQL очень быстр при установке нового соединения, это все еще стоит - во время установки потока, и во время установки TCP/IP от Вашего веб-сервера. Это примечательно на достаточно высоком транспортном сайте. К сожалению, PHP не имеет никаких средств управления на персистентности соединений. Таким образом, ответ должен понизить неактивный тайм-аут в MySQL длинный путь (как вниз к 20 секундам), и к размеру кэша потока. Вместе, это обычно работает замечательно хорошо.
На обороте, Ваше приложение должно уважать состояние соединения. Лучше, если это не делает предположений о том, в каком состоянии сессия находится. Если Вы используете временные таблицы, то использование СОЗДАЕТ, ЕСЛИ НЕ СУЩЕСТВУЕТ, и TRUNCATE TABLE помогает много, как делает именование их исключительно (такое как включение как идентификатор пользователя). Транзакции являются более проблематичным битом; но Ваш код может всегда делать ОТКАТ наверху на всякий случай.
Очень маловероятно, что Вы достигнете 10 000 соединений. Во всяком случае перейдите в официальный источник . (Шахта Emphasis).
, Если постоянные соединения не имеют никакой добавленной функциональности, для чего они хороши?
ответ здесь чрезвычайно прост - эффективность. Постоянные соединения хороши, если издержки для создания ссылки на SQL-сервер высоки. Действительно высоки ли эти издержки, зависит от многих факторов. Как, то, какая база данных это, находится ли это на том же компьютере, на котором находится Ваш веб-сервер, как загруженный машина SQL-сервер находится на, и т.д. нижняя строка - то, что, если то соединение наверху высоко, постоянные соединения значительно помогают Вам . Они заставляют дочерний процесс просто соединяться только однажды для его всей продолжительности жизни, вместо каждого раза он обрабатывает страницу, которая требует соединения с SQL-сервером. Это означает, что для каждого ребенка, который открыл постоянное соединение, будет иметь его собственное открытое постоянное соединение к серверу. Например, если бы у Вас было 20 различных дочерних процессов, которые выполнили сценарий, который установил постоянную связь с Вашим SQL-сервером, у Вас было бы 20 различных соединений с SQL-сервером, один от каждого ребенка.
Примечание, однако, что это может иметь некоторые недостатки при использовании базы данных с ограничениями соединения, которые превышены персистентными дочерними соединениями. Если Ваша база данных имеет предел 16 одновременных соединений, и в ходе занятой сессии сервера, 17 дочерних потоков пытаются соединиться, каждый не будет в состоянии. Если существуют ошибки в Ваших сценариях, которые не позволяют соединениям закрываться (такие как бесконечные циклы), база данных только с 16 соединениями может быть быстро затоплена. Проверьте свою документацию базы данных на информацию об обработке заброшенных или неактивных соединений.