Ян Александров, ваше предложение описывает html вёрстку, такие вещи решаются шаблонизаторами, а php уже очень давно универсальный язык.
Match отличается от switch сравнением с учётом типов, и уже только это даёт ему право на жизнь.
planc, так чем он хорош?
Понятно, что сборку можно ускорить, но вопрос в том, а надо ли собирать из исходников и тратить на это время? Какие плюсы перевешивают эту трату времени?
Владимир Коротенко,
1) Имеется ввиду обход ограничений на подключение извне, если клиент за NAT? Из выражения "пробивание сетевых фильтров" мало что понятно.
2) Зачем между 1 сервером и 1 клиентом более 65000 соединений?
runapa, если вопрос в том, не является ли операция update тем же самым, что и delete и insert - для MySQL нет, не является, поэтому update в ней будет проходить быстрее.
FanatPHP, согласен, здесь можно обойтись и без исключений, все-таки исключение - вещь исключительная. Но автор пишет про некорректные входные параметры, т.е. тут не факт, что это логика программы. И раз необходимо прерывать выполнение кода с неуспешным статусом на исключение это вполне тянет.
Т.е. если мы просим калькулятор разделить число на 0, то это явно логика и нет повода кидать исключение. Но если, мы передаем в код идентификатор сервера с которым нужно работать, а такого сервера нет, то вполне можно бросить исключение. Из приведенного кода не сильно понятно какой это случай.
В дополнение, то что вы хотите вывести что-то на экран, нисколько не отменяет, что нужно бросить Exception. Т.е. выводите что нужно и снова бросаете тот же Exception, без всяких die(). А так как вы скорее всего хотите обрабатывать так, все исключения, то все это нужно вынести в общий обработчик исключений.
Раз MySQL пишет, что запись есть, значит она есть. При поиске ошибок, нужно локализовывать проблему. В данном случае, не помешало бы убрать циклы и оставить только вставку и все бы стало на свои места.
Node.js на котором будем запускать socket.io тоже однопоточный. Пока вы не используете потоки, любой скрипт у вас однопоточный. Начнете пользовать потоки - будет многопоточный, php тоже есть с поддержкой потоков. Опять же работа с потоками не панацея и не такое уж простое занятие, не важно на node.js или php. Из плюсов node.js - там неблокирующий IO, но сколько на этом выиграем зависит от задач. Из минусов php - там реализация коннектов сокетов через файловые дескрипторы, с соответствующими лимитами, но, вероятно, при такой нагрузке уже стоит горизонтально масштабироваться.
Чтобы не "становится в очередь и ждать выполнения заданий друг у друга" не нужно обрабатывать задания сервисом сокетов, а передавать эти задания воркерам. При таком раскладе, можно сам сервис написать, например, на Go (там кода будет немного), а воркеры уже на чем удобнее и быстрее (на том же php).
Многие удобные вещи, которые предоставляет socket.io не будут работать при использовании web-socket (broadcast, масштабирование с аутентификацией через куку). Т.е. мы тянем достаточно тяжелую библиотеку, которая предоставляет много полезного, но стоит ли это делать только ради websocket, если все остальное нам не нужно? Тут вопрос к автору, ему нужен любой обмен или именно web-socket?
Поправьте меня, если я ошибаюсь.
Т.е. вы монтируете диск в память...
Еще раз сначала, вы в СУБД материализуете таблицу, т.е. сохраняете ее на диск, а не держите в памяти, а затем диск на который материализуете, размещаете в памяти?! Зачем?..
Андрей Афонченко, наверняка не скажу, по-сути не работал никогда с Access. Просто посмотрел доку, там пишут, что нет пакетной вставки. И как я понял, несколько команд подряд не может идти в 1 запросе. Из того что пишут, такое возможно только через костыль insert select.
Match отличается от switch сравнением с учётом типов, и уже только это даёт ему право на жизнь.