[swagerstom]

Mydevil: Query took 1.1618 seconds
LinuxPL: Query took 0.0069 seconds

to samo zapytanie, te same dane, tańsze linuxPL xD

fajna ta usługa, taka nie za szypka @MyDevil

żeby nie było, to nie są jakieś tam przypadkowe wyniki tylko trochę to potestowałem

#hosting #linuxpl #mydevil

[MyDevil]

Ta różnica to query_cache włączone po stronie linuxpl. U nas jest wyłączone z powodu kilku dobrze znanych faktów:
- query_cache potrafi w wielu wypadkach zmniejszyć wydajność zapytań, przykłady prosto od Percony: https://www.percona.com/blog/2015/08/07/mysql-query-cache-worst-enemy-best-friend/
- query_cache zostało domyślnie wyłączone dla MySQL 5.7. Można je włączyć ale nie jest to zalecane przez twórców MySQL.
- query_cache ostatecznie zostało usunięte z MySQL 8.0 - czyli prędzej czy później każdy hosting, który robi aktualizacje wyłączy query_cache i zacznie optymalizować działanie

[swagerstom]

@MyDevil co mogę doraźnie zrobić, oprócz przepisania połowy backendu ( ͡° ͜ʖ ͡°)

[MyDevil]

@swagerstom: Można użyć innych mechanizmów cache, takich jak: Redis, Memcached lub APCu, które nie mają żadnych skutków ubocznych. Może to wymagać zmian w aplikacji.
Inną możliwością jest optymalizacja uruchamianego kodu.

Czasami "przepisanie połowy backendu" nie jest takim złym pomysłem ( ͡° ͜ʖ ͡°)

[radekrad]

@swagerstom: @MyDevil: ja w swojej aplikacji miałem jedno bardzo nieoptymalne zapytanie. Na biedaarubie wykonywało się koło 1s, na mydevil koło 0.3s. Trochę żałowałem, że optymalizowałem aplikację, bo jak rozumiem, na mydevil nie ma żadnych limitów, a na VPS miałem tylko 1 core ( ͡° ͜ʖ ͡°)

Jak to możliwe, że udało Ci się zrobić zapytanie, które wykonuje się ponad sekundę? Jesteś pewien, że jest

[swagerstom]

@radekrad: tak średnio bym powiedział ( ͡° ͜ʖ ͡°)

znalezienie najnowszej daty dla około 50 zgrupowanych encji w milionowej tabeli