Роман

Почитайте, optimization.guide и вот вам немного теории:

Кешировать можно:

• целиком всю страницу (для каждой страницы своя запись в кеше)
  
• отдельные части сайта
  

Кешировать можно в файлах:

• генераруя готового html
  
• генерируя html+php, так работают smarty и прочие шаблонизаторы собирая множество шаблонов в один
  
• в виде бинарного содержимого, сюда и готовый html и готовые значения вычислений и прочее
  
• в виде сериализованного массива с чем угодно, от предыдущего пункта отличается только форматом хранения
  

Кешировать можно в базе:

• в mysql/postgresql и прочих SQL - будет храниться на диске и горячие данные в памяти
  
• в mysql/postgresql и прочих SQL в in-memory таблицах - будет храниться в оперативке, но без дополнительных усилий кеш пропадёт при рестарте сервера
  
• в in-memory базах данных, часто это memcache, redis и прочее - опять таки выключили сервер - данные пропали
  
• в in-memory базах данных с сохранением на диск, это Tarantool, memcachedb и прочие если там заявлена такая функциональность
  

Так же можно:

• кешировать всё кроме вставок динамики
  
• кешировать куски вставляя их в динамику
  

Это два противоположных подхода которые при особом желании можно смешивать в рамках одного проекта.

Обновлять кеш можно:

• при каждом запросе проверяя что старый кеш устарел
  
• предкеширование - отдельным кроном/демоном/сервисом генерировать кеш раз в N минут
  
• по мере изменения данных сбрасывать кеш и следующий запрос сгенерирует новый
  
• по мере изменения данных сбрасывать кеш путём генерации сразу нового и замены старого на новый
  

Кеш можно хранить:

• на том же сервере что и сайт - нет задержек в сети, но зато ресурсы теже, CPU, диск, оперативная память
  
• на внешнем сервере - задержки в сети, зато ресурсы отдельно
  

Можно совмещать разные виды кеширования для разных данных. Можно кешировать только результат работы функций (вычисления, данные), а шаблоны не трогать, можно вместе с шаблонами, но тогда каждое изменение шаблонов повлечёт сброс всего кеша где он участвует.

Если используете CMS/CMF - посмотрите готовые плагины для кеширования. Если у вас не sharing-хостинг с мини-сайтом - озаботтесь профилированием (xhproof) и мониторингом, это поможет понять где и что кешировать.

Так же стоит рассмотреть кэширование байт-кода:

• OpCache
  
• APC
  
• XCache
  

Стоит прочитать вот эту статью:
Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache https://habrahabr.ru/post/264775/

Так же стоит:

• увеличить буферы в MySQL (если памяти много)
  
• потюнить другие системы, например поставить nginx вместо apache, раздавать статику с другого хоста
  
• и конечно же - посмотреть как долго работают SQL запросы и по возможности их облегчить
  

Кеширование в MySQL с использованием HandlerSocket:

• данные хранятся в MySQL innodb базе, а значит чтение и запись можно делать как по старинке через SQL так и через HandlerSocket
  
• можно сделать любое количество колонок, лишь бы это позволял MySQL
  
• быстрая вставка
  
• быстрая выборка
  
• бинарный протокол передачи данных
  
• есть несколько библиотек для PHP, как относительно новых так и старых
  
• в Percona Server (форк MySQL) HandlerSocket.so есть в поставке по умолчанию, разве что нужно включить
  
• в MySQL необходимо собрать HandlerSocket самостоятельно и включить в MySQL
  

Можно почитать вот тут:

• То, что вы хотели знать о HandlerSocket, но не смогли нагуглить, Сергей Аверин - https://www.youtube.com/watch?v=qHqdhJ9ziik
  
• Gentoo Overlay с HandlerSocket, давно не обновлял но вроде работает - https://github.com/mantyr/overlay-gentoo-flower
  
• HS кеш, тоже давно не обновлялся, но как пример сойдёт - https://github.com/mantyr/php-hscache
  
• PHP Extension для HandlerSocket, не содержит последних коммитов, но зато, наверное, единственое место где есть точное описание всех методов и входящих параметров, https://github.com/mantyr/php-ext-handlersocketi
  

При использовании в выборке sparse index на "неоднородных" документах нужно использовать hint, плюс не нужно добавлять $exists. И конечно же, не нужно забывать, что индекс с 2мя значениями (1:0 / true:false и тд) всегда малоэффективен.

Документы неоднородны, когда отсутствуют какие-то свойства, которые есть у других документов, и по этим свойствам строится индекс.

db.documents.createIndex( { is_processed: 1 } , { sparse: true } )

db.documents.find({is_processed: 1}).hint({is_processed: 1}).limit(200)

или

db.documents.find().sort({is_processed: 1}).hint({is_processed: 1}).limit(200)

fdisk -l

фронтенд у тебя все правильно делает
options сам браузер отправляет
убей свой сервер и посмотри nc -lp 3500

бэкенд должен заголовками ответить что все норм
https://developer.mozilla.org/en-US/docs/Web/HTTP/...

чтобы на бек-энд приходил application/json ?

последний параметр не правильный у тебя

post("http://localhost:3500/login", JSON.stringify({ email: email, password: password }), {headers: this.headers})

Примерная схема работы:

1. Клиент вводи логин и пароль
   
2. Сервер генерирует jwt токен
   
3. Сервер сохраняет в куках или отправляет токен клиенту (зависит от вашего проекта)
   
4. Если токен был отправлен клиенту, он его сохраняет в sessionStorage или localStorage или еще куда
   
5. Клиент обращается к серверу:
   — если токен в куке, сервер вытаскивает из куки и проверяет валидность.
   — если токен храниться у клиента, он должен отправлять этот токен с каждым запросом на сервер
   
   

Ведь получается некрасиво будет, если пользователь ходит по сайту и ему в какой то момент при запросе ресурса приходит отлуп, с требованием авторизации

Можно пересоздавать токен, для этого клиенту не обязательно вводить логин и пароль заново.

Да, с помощью xsd можно автоматически сделать java-классы.
Либо средствами среды, либо через онлайн сервисы (первый попавшийся: pojo.sodhanalibrary.com/pojoFromXSD.html)

Лучше в routes.rb :
resources :requests
И контроллер RequestsController

Данный фремвор разработан для создания SPA приложений, по умолчанию он сбрасывает поведения для ссылок по умолчанию, я к сожалению не сильно знаком с данным фремворком.
Как вариант можно сделать так:

<a ng-href="[[msg.User.Url]]" ng-bind="msg.User.Name" ng-click="myCustomRedirect([[msg.User.Url]])"></a>

а в контролере

$scope.myCustomRedirect = function(url){
    location.href = url;
}

Попробуйте что нибудь вроде

m := melody.New()
m.Upgrader.CheckOrigin = func(r *http.Request) bool { return true }

Катастрофических последствий не влечет. CheckOrigin добавляет мало безопаcности на стороне сервера потому что заголовок Origin легко подделывается. Браузер из коробки должен держать 30 ws connection с одним хостом и 200 всего.

В агрегациях монги, начиная с 3.2 есть аналог LEFT JOIN - $lookup. В mgo агрегации реализуются через Pipe. Маленький пример на коленке, в поле news при выборке попадают все новости автора:

package main

import (
	"encoding/json"
	"fmt"
	"gopkg.in/mgo.v2"
)

type (
	obj map[string]interface{}
	arr []interface{}
)

func main() {
	mongo, err := mgo.Dial("localhost")
	if err != nil {
		panic(err)
	}

	info := []obj{}

	if err := mongo.DB("myDB").C("authors").Pipe(arr{
		obj{"$match": obj{"banned": false}},
		obj{"$lookup": obj{"from": "news", "localField": "_id", "foreignField": "authorID", "as": "news"}},
	}).All(&info); err != nil {
		fmt.Println("Error:", err)
	}

	printJSON(info)
}

func printJSON(t interface{}) {
	j, _ := json.MarshalIndent(t, "", "\t")
	fmt.Println(string(j))
}

Можно грузить один раз.

В контроллере

cities: function() {
    //Получаем список городов которые есть в памяти
    var cities = this.store.all('city');

    //Если города еще не загружались, берем их с сервера.
    if (!cities.length) {
        cities = this.store.find('city');
    }

    return cities;
}.property()

В шаблоне

{{view "select"
       content=cities
       optionValuePath="content.id"
       optionLabelPath="content.name"
       value=session.user.cityId}}

Соответственно у вас должна быть модель City.