justify-content: space-between
и gap
одновременно?Если рассматривать аналогию с php, то там каждый запрос отправляется с новым подключением к базе.Это не так. Соединение открывается на все время выполнения скрипта, и закрывается автоматически по завершении работы всей цепочки вызовов. В процессе, одно соединение может выполнить стопицот запросов.
На сколько целесообразно "пытаться" держать соединение, или все же просто по аналогии с php?Вот тут точного ответа не дам, однако в пхп стараются избегать персистент соединения, так как пул соединений не бесконечный, и чем быстрее закроется соединение, тем быстрее можно освободить очередь для открытия нового, таким образом с небольшой задержкой можно обслужить очередь из сильно превышающей пул очереди. А с одним соединением начинается жонглирование запросами внутри 1 соединения, что приводит к блокировке кучи пользователей пользующихся 1 соединением с бд, вместо локально тормозящего 1 юзера в случае открытия/закрытия...
Вы можете использовать это как грубый «набор правил»:
YES , использовать постоянные соединения, если:
- Есть только несколько приложений/пользователей, обращающихся к базе данных, т.е. вы не получите 200 открытых (но, вероятно, бездействующих) подключений, потому что на одном хосте есть 200 разных пользователей.
- База данных работает на другом сервере, к которому вы обращаетесь по сети.
- (Одно) приложение очень часто обращается к базе данных
NO , не используйте постоянные соединения, если:
- Вашему приложению нужно обращаться к базе данных всего 100 раз в час.
- У вас есть много веб-серверов, обращающихся к одному серверу базы данных.
- Вы используете Apache в режиме prefork. Он использует одно соединение для каждого дочернего процесса, что может довольно быстро увеличиваться.
Использование постоянных подключений значительно быстрее, особенно если доступ к базе данных осуществляется по сети. Это не имеет большого значения, если база данных работает на той же машине, но все же это немного быстрее. Однако, как следует из названия, соединение является постоянным, т. е. остается открытым, даже если оно не используется.
Проблема в том, что в «конфигурации по умолчанию» MySQL разрешает только 1000 параллельных «открытых каналов». После этого новые подключения будут отклонены (эту настройку можно изменить). Итак, если у вас есть, скажем, 20 веб-серверов со 100 клиентами на каждом из них, и каждый из них имеет доступ только к одной странице в час, простая математика покажет вам, что вам потребуется 2000 параллельных подключений к базе данных. Это не сработает.
Следовательно: используйте его только для приложений с большим количеством запросов.
document.onpaste = function(event){
var items = (event.clipboardData || event.originalEvent.clipboardData).items;
console.log(JSON.stringify(items)); // will give you the mime types
for (index in items) {
var item = items[index];
if (item.kind === 'file') {
var blob = item.getAsFile();
var reader = new FileReader();
reader.onload = function(event){
console.log(event.target.result)}; // data url!
reader.readAsDataURL(blob);
}
}
}
@mysql_query()
уже одного этого кусочка хватает для того, чтобы сильно усомниться в скиллах.