Szybkość i efektywność dostępu do danych w php, ... czyli jak utrzymać otwarte API dalej otwartym? Opcje

[janlgorski]

1. Mam otwartą część serwisu (Access-Control-Allow-Origin: *), która zwraca przez ajax pewne szybko zmieniające się wartości (kilka liczb, format json). Jak najefektywniej zaprojektować dostęp do danych, zakładając, że skrypt będzie wykonywany z dużą częstością przez zewnętrznych użytkowników?

Całość przechowywanych danych ma 10kB.

1. mySQL - nawiązanie połączenia i pobranie pojedynczej wartości ( to jest chyba nieefektywne, zwłaszcza nawiązanie połączenia)
2. pliki txt - nie jestem pewien jak efektywne jest otworzenie/zamknięcie pliku?
3. tworzenie pliku php przez php i 'include' nowo utworzonego pliku z wyliczonymi wartościami w formie tablic.
4. Dopisanie tablicy wartości bezpośrednio do wywoływanego pliku php, bez 'include'.
5. inna opcja, której nie wziąłem pod uwagę.

Moim celem jest nie tyle redukcja transferu serwer - klient, co optymalizacja użycia procesora na serwerze.
Pytam, ponieważ pojawiły się zewnętrzne skrypty, które wywołują mój kod z dużą częstością i zaczynam to widzieć na moich limitach użycia procesora. A nie chciałbym zamykać otwartego API, do tej pory używanego przez 'normalnych' użytkowników do dołączania widgetu na stronie.

[ano]

Przechowuj dane w Redis'ie/memcached.
Np w przypadku Redisa dla marnej klasy serwera daje on wydajność na poziomie > 40.000 req/s.
Wtedy wąskim gardłem będzie Twoj aplikacja PHP która pewnie obsługuje 400req/s.

[janlgorski]

Fajny pomysł, ale na hostingu dzielonym nie mam tych modułów zainstalowanych. Chciałbym skorzystać z dostępnego rozwiązania.

[Crozin]

Jeżeli na serwerze masz dostęp do APC czy innego akceleratora, który pozwala na przechowywanie "skompilowanego" kodu PHP cały czas w pamięci zapisanie danych do pliku w formie PHP-owskiej tablicy będzie jednym z szybszych rozwiązań:

[PHP] pobierz, plaintext 
#dane.php
 
return array(...);
 
#plik.php
 
$data = require 'dane.php';
[PHP] pobierz, plaintext 

Jednak tutaj największe obciążenie generuje zapewne sama obsługa żądań HTTP, może masz możliwość skorzystania z WebSockets? W znacznym stopniu skróciłbyś wtedy opóźnienia na linii serwer -> klient oraz ograniczył pracę procesora. Jeżeli zależy Ci na wysokiej kompatybilności ze starszymi przeglądarkami, zawsze możesz utworzyć dwa punkty wejścia do Twojego API: pierwsze, preferowane, wykorzystujące WS; drugie, zapasowe, oparte na AJAX-ie.

[janlgorski]

Niestety nie mam (hosting dzielony). Czyli korzystając z dostępnych narzędzi 'include' z tablicą tworzoną dynamicznie jest najlepszym rozwiązaniem?

Użytkownik końcowy - webmaster, generuje sobie 'widget', który wkleja na stronie lub blogu. Widget ten za pomocą skryptu js pyta serwer o odpowiedź. Ale są już osoby, które z mojego mechanizmu korzystają w sposób przeze mnie nie przewidziany i niejako nie autoryzowany.