Oleg

150911 14:58:19 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
150911 14:58:19 [Note] - '127.0.0.1' resolves to '127.0.0.1';
150911 14:58:19 [Note] Server socket created on IP: '127.0.0.1'.
150911 14:58:19 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
150911 14:58:19 [ERROR] Do you already have another mysqld server running on port: 3306 ?

порт 3306 занят

выясните кто это сделал и уберите нахала.

Вообще сложный вопрос "откуда эта информация".
Для меня эта информация из разряда "а почему птицы летают" - т.е. само собой разумеется :)

Вообще, если искать информацию, то информацию подобного типа стоит искать из фундаментальных книг по строению компьютеров, программм, компиляторов и тп.
Так же, что происходит при переходе внутрь функции - идёт вызов функции, передача данных в функцию и тп.

агрегатор:
+ легче подключать много платёжек
+ одна точка саппорта, если проблемы
+ один договор на всё
- комиссия может быть больше
- если проблемы у самого агрегатора - денег вы не получите.
- иногда саппорт агрегатора бывает не адекватный
+ иногда через агрегатора можно получить лучше комиссию (при больших объёмах покупок)

напрямую:
- если нужно много платёжек - то замучаетесь заключать договора со всеми (если вы фирма и всё в белую)
- куча поддержек
+ иногда - больше функционала
+ обычно - лучше комиссия
+ диверсификация - вебмани упал, а яндекс продолжает работать, как пример.

Обычно стоит подключать смешанный режим:
основные платёжки - напрямую
остальные - через агрегатор.

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

php.net/manual/en/features.file-upload.errors.php
UPLOAD_ERR_NO_TMP_DIR
Value: 6; Missing a temporary folder. Introduced in PHP 5.0.3.

не указана временная папка

укажите ещё через например .htaccess:
php_value upload_tmp_dir /home/путь до временной папки/

построение сетей, создание протоколов, написание низкоуровневых протоколов общения с сервером, нагрузка и тп, то :
> 1. Что то низкоуровневое типа C, теории вычислений, компиляторов и изучения детально стека протоколов + какой-то скриптовой язык.Комбинаторика, криптография.

Причём стек в обязательном порядке.

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

Событие может быть не привязано ко времени, т.е. делать " в любое время".

Например:
"позвонить узнать о ценах на машину" - 15 минут
"подготовить рапорт о том почему мне поднять зарплату" - 1 час
"проверить прогресс проекта" - полчаса

При этом, событие может быть в любое время 7 августа.. но только с 8 утра по 19 вечера.

Т.е. если не сделал до 18.00 и длительность - час то надо срочно переключаться на него :)

Как это оформить именно у вас - не знаю.
Вариант:
1. надо вводить день
2. надо вводить длительность
3. надо ввести "напомнить не позднее чем в 18.00"
Причём п3 может и не быть.

И выводить все события такие - как события на начало дня.

Хром, или любой браузер ?

Недавно столкнулся с подобным поведением:
superuser.com/questions/565409/chrome-how-to-stop-...

Т.е. хром всегда редиректил а https:// версию.

смотрите:
select UNIX_TIMESTAMP();
select FROM_UNIXTIME(UNIX_TIMESTAMP());

Самый простой способ:

В момент изменения списка друзей - пересчитываем вручную друзей до 5ого уровня и сохраняем в таблице вида:
user_id,friend_id, level

Так как редактирование списка друзей - событие реже чем выборка" - то это имеет смысл чтобы выборка была быстрая.

Правда на больших объёмах - (Сотни людей) - могут быть проблемы :)

2ой способ, в момент выборки, так как у нас ограничен уровень вложения: (но сражу скажу что этот способ намного хуже)

друзья первого уровня:

select friend_id from users_friends where user_id  =1;

Друзья второго уровня:

select lvl2.friend_id 
from users_friends as lvl1
right join users_friends  as lvl2 on lvl2.friend_id=lvl1.user_id
where lvl1.user_id  =1;

Дальше уровни по аналогии

а чтобы это всё вместе возвращало:

select friend_id from users_friends where user_id  =1 UNION
select lvl2.friend_id  from users_friends as lvl1 right join users_friends  as lvl2 on lvl2.friend_id=lvl1.user_id where lvl1.user_id  =1;

Правда на больших объёмах производительнсть будет хромать.

использую такую таблицу:
users_friends: -друзья юзеров
user_id, friend_id (причём для каждой "дружбы" - две записи)

способ 3:
делать подобную выборку как в п1 и хранить в кеше локальном (требуется 5 запросов

Способ 4:
написать процедуру которая делает то же самое что в п1-п2

если вы хотите проверить "изменил ли запрос что то " - то можете просто проверять, affected_rows.

Правда если вы два раза выполните один и тот же апдейт как у вас в примере - то второй раз он сообщит что изменено 0 строк.. потому что нечего менять.

2 варианта я вижу:

1. LOAD DATA - выше уже дали ссылку.

2. insert сразу многих строк:

Пример:
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);

dev.mysql.com/doc/refman/5.6/en/insert.html

+ лучше всего тюнинг сервера, чтобы он был готов к таким объёмом (миллион строк - это ничего не говорит)

а как именно сервер не справляется ? (миллион строк - это ничего не говорит)

1. забыть про скорость набора после "определённого уровня".

"определённый уровень":
1. ты можешь писать смотря в экран и одновремённо думать о том, как программа будет работать.
2. на клавиауру вообще не смотришь, чувствуешь её на ощупь, т.е. фактически голова говорит "напиши слово", и пальцы сами работают, а голова в этот момент думает о печеньках :)


Если ты можешь печатать и при этом думать о клавиатуре - структуре функции/кода - можно дальше не ускоряться.

Причина почему дальше безсмысленно:
особого прироста не будет.
основное время идёт на продумывание структуры/архитектуры, а не на сам код.

2. продумывать структуру кода, чтобы она была удобная, легко понимаемая и предсказуемая.

Причина:
читать и понимать этот код придётся ещё не 1 раз.

3. лёгкие для понимания названия переменных, функций, классов.

4. тренироваться. анализировать постоянно старый код, в том числе его переписывать чтобы было лучше.