Часы работы внешнего экземпляра GAE увеличиваются без использования приложения (python-backend)

Часы работы моего внешнего интерфейса GAE продолжают увеличиваться, даже если приложение не используется и нет запущенных экземпляров (потому что я вручную закрыл их !!). В моем вопросе есть несколько подвопросов, вот они:

  1. Что является основным компонентом, влияющим на часы работы внешнего экземпляра? В моей текущей реализации системы я широко использую следующие ресурсы Google: Memcache, очередь задач и хранилище данных NDB. Я точно знаю, что хранилище данных не имеет большого отношения к интерфейсным экземплярам (или, может быть, я ошибаюсь), но затрачивает ли Memcache часы работы внешних экземпляров? Вплоть до вчерашнего дня мое приложение работало отлично, и часы экземпляра использовались (как и следовало ожидать), поскольку использовалась очередь задач. Это заставило меня поверить, что основным фактором было использование очереди задач и отправка нескольких запросов за короткий период времени. Но сегодня утром я добавил дополнительное использование кэша памяти, и он начал действовать. Кроме того, влияют ли статические ресурсы на часы работы экземпляра?

  2. Как оптимизировать приложение, что нужно учитывать в первую очередь? Вызовы Google API, URL-вызовы в целом, снова memcache?

Информация о приложении:

В моем файле app.yaml есть некоторая информация о конфигурации:

  • default_expiration: 15m (у меня это было 1 час назад, но изменилось для целей тестирования)
  • instance_class: F2 (мне нужно, чтобы он был F4 для некоторой обработки, но снова изменил его на F2 для целей тестирования)
  • threadsafe: да

Мне нужно иметь четкое представление об экземпляре часов, сообщения, которые я здесь прочитал, недостаточно ясны! Если у вас есть глубокое понимание того, как Google вычисляет часы работы внешнего экземпляра, дайте мне знать! что заставляет его расти, как управлять этим и все такое.

Дополнительный визуальный контекст:

Краткое описание процесса

Как вы видите на этом рисунке, http://www.example.com http://beta.example.com https://example.com https://www.example.com https: // ...

Я бы хотел сделать следующее: используя Apache, перенаправить все следующие URL-адреса:

http://example.com
http://www.example.com
http://beta.example.com
https://example.com
https://www.example.com
https://beta.example.com

в то же место: https://beta.example.com . Я близко, но не совсем. Вот что у меня есть:

NameVirtualHost xxx.xxx.xxx.xxx:80
NameVirtualHost xxx.xxx.xxx.xxx:443

### rewrite scheme via http://stackoverflow.com/questions/1100343/apache-redirect-from-non-www-to-www                                    
<VirtualHost xxx.xxx.xxx.xxx:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/html/example
    CustomLog /var/log/httpd/example-log combined
    ErrorLog /var/log/httpd/example-log
</VirtualHost>

<Directory /var/www/html/example>
    RewriteEngine on
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule ^(.*)$ https://beta.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    Options -Indexes
    Options +FollowSymLinks
    DirectoryIndex index.php
</Directory>

<VirtualHost xxx.xxx.xxx.xxx:80>
    ServerName beta.example.com
    DocumentRoot /var/www/html/example-beta
    CustomLog /var/log/httpd/example-beta-log combined
    ErrorLog /var/log/httpd/example-beta-log

    <IfModule mod_rewrite.c>
              RewriteEngine on
              # redirect all http -> https                                                                                             
              RewriteCond %{HTTPS} off
              RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
    </IfModule>
</VirtualHost>

<VirtualHost xxx.xxx.xxx.xxx:443>
    ServerName beta.example.com
    DocumentRoot /var/www/html/example-beta
    ErrorLog /var/log/httpd/example-beta-log
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x" combined_ssl
    CustomLog /var/log/httpd/example-beta-log combined_ssl

    SSLEngine on
    ### SSL details omitted for clarity.
</VirtualHost>

Что я получаю из этого:

http://example.com => https://beta.example.com
http://www.example.com => Content for www.example.com (/var/www/html/example)
http://beta.example.com => https://beta.example.com
https://example.com => https://example.com (correct content but wrong url)
https://www.example.com => https://www.example.com (correct content but wrong url)
https://beta.example.com => https://beta.example.com

Вероятно, стоит отметить, что мой ssl-сертификат полностью поддерживает подстановочные знаки, так что я должен хорошо разбираться в этом, и все материалы SSL, похоже, работают ( даже если страницы обслуживаются под https://example.com ). Между тем, файлов .htaccess нет - я пытаюсь сделать все через конфигурацию apache.

Итак, проблема в том, чтобы https://example.com правильно перенаправлял, с помощью и без префикса www. Есть какие-нибудь советы? Спасибо!

1
задан 14 June 2016 в 19:28
1 ответ

Из того, что я читаю, вам понадобятся две отдельные записи VirtualHost, одна для HTTP, а другая для HTTPS. Они различаются портом (: 80 для HTTP и: 443 для HTTPS), а также тем, что у вас есть раздел SSL On для HTTPS. У каждого должны быть перечислены все имена:

ServerName  beta.example.com
ServerAlias example.com www.example.com

Тогда у вас будет все тот же DocumentRoot и другая информация, перечисленная там. Для HTTP VirtualHost вы уже знаете, что вам нужно перенаправить, потому что вы знаете, что хотите HTTPS, поэтому вам понадобится только RewriteRule:

RewriteRule ^ https://beta.example.com%{REQUEST_URI} [R=301,L]

Для HTTPS VirtualHost вам понадобится тот же RewriteRule, но вам также нужно будет добавить условие:

RewriteCond %{HTTP_HOST} !^beta\.example\.com$
RewriteRule ^ https://beta.example.com%{REQUEST_URI} [R=301,L]

RewriteCond предназначен для предотвращения бесконечного перенаправления.

Это позволит вам управлять перенаправлениями в одном месте. Если у вас нет причин создавать VirtualHost для каждого домена, то проще иметь его.

1
ответ дан 3 December 2019 в 23:44

Теги

Похожие вопросы