ptprog

From the error, I assume you did not specify the endpoint/hostname wit redis-cli. To connect to ElastiCache using redis-cli, you should use a command like: redis-cli -h <primary endpoint hostname> -p 6379 --tls --askpass Replace <primary endpoint hostname> with the appropriate value for your instance. Drop the --tls if you do not have TLS enabled. If this fails, it likely means there is an issue preventing your host to connect to the cluster. If it succeeds, them its likely the problem is on the connection from IPS.

Start by SSHing into the host, and trying to connect to Redis using redis-cli. In this way, you should be able to figure out if the issue is on IPS or not. Is you security group for Elasticache allowing inbound connections on port 6379? Also, I assume that when you say that you "entered the server address", you mean the "Primary endpoint", right?

I recently noticed an increase on cache misses from Redis. I saw that this started around to time of the update to 4.7.18. Also, the requests causing the miss rate increase seem to be for requests `GET "<hex string>_<long hex string>_str__nodeSyncTimes"`. Not sure whether this is expected, but after inspecting the code, I noticed some suspicious curly brackets in `\IPS\Node\DelayedCount::checkUpdateTime` after the first catch. Removing them solves the issue, but I'd like to confirm whether this is indeed a bug or not.

I tried with both the latest version (2.16?) and 2.1, and none worked (the index was not created for some reason). With ElasticSearch 7.17 it seems to work fine. I'm still making tests and I'll try again OpenSearch, but most likely I'll stay with ElasticSearch in the end. Not sure which Debian version you are using, but probably you can use Docker to run ElasticSearch.

In my setup, the CSS resources referenced in the head are loaded in parallel with a CSS that is preloaded (editor.css), so my expectation was for the preload to not have impact. In a quick experiment, I did not see any difference in how the CSS was loaded (CSS is queued and starts a few ms after the editor.css, which is preloaded, regardless of whether all the CSS uses preload). Based on my understanding of the preload, I would not expect it to harm performance, but I also do not expect it to help. The idea of the preload is to load in advance resources that the browser would not be aware of otherwise (e.g. resources that are not referenced in the HTML directly from the beginning, like it seems to be the case of the editor.css or the fontawesome). But for the "normal" CSS, the browser will see that the resources need to be loaded at the same time without the preload.

Was there any development on this? There are dozens of CKEditor files currently not being served by the CDN.

When using a rule of type "Reaction is given", what is the meaning of the milestone? For example, if we set it to "It is their 10th reaction", will the rule be applied: When a specific post receives the 10th reaction? When a user receives the 10th reaction considering all posts? When a user gives the 10th reaction considering all posts? Other? In other words, is the milestone for the user giving the reaction, or for the receiving user? And do we count the reactions on a specific post, or for all posts? (I actually think all the variants should be supported, but for now I'm wondering which one is currently implemented.)

Do you mean to send or to receive emails? You can use Amazon SES to send emails for any email address you own (you just have to configure your email client with Amazon SES SMTP server data). If you also want to receive email in a "normal" email client, you will need more than Amazon SES. You can use Amazon WorkMail, for example to receive emails (but there are cheaper options for receiving emails).

You should use a separate service for that. Then you can use Amazon SES for sending the emails, which should be the cheapest solution you can get.

Ok, so you certainly have spare memory available on you server 😄 You should try Redis. If you have some analytics solution, you should be able to monitor the evolution of the performance on your site.

I haven't looked in detail about how IPS uses cache (e.g. how expensive to compute are the values cached), but with the reduced number of options we have now, and assuming you have spare memory available, I expect Redis to be a safe bet. IPS can achieve very high cache hit ratios. So, my expectation is that using cache will improve performance. Since now using cache requires using Redis for data storage, I would be surprised if any other data storage option was better. Again, I'm assuming you have spare memory in your server. Also, as @Thomas P mentioned above, using Elasticsearch for search may be a better change to start with. Out of curiosity, what is the current size of you DB?

From what I can see, in recent versions you either use Redis for "Data Storage Method", or you won't be able to select any "Caching Method" (i.e. to use Redis as "Caching Method", you also need to use Redis as "Data Storage Method"). So, I guess Redis is the way to go.

Regarding hosting providers, I have been using Linode for a couple of projects, and I'm happy with their service. You also have Amazon Lightsail and Vultr with similar prices. If you are going to use a VPS and manage it yourself, you can easily configure Lets Encrypt from command line. This should take less work than buying a certificate.

My terminal supports UTF-8 chars, and I could see emojis on the posts that still had the emojis. But just in case this was an issue with a specific emoji, I also used the MySQL HEX function to see the hexadecimal representation of the char stored and confirmed it was a plain "?". It looks like this bug is known for 4 years: https://jira.mariadb.org/browse/MDEV-11777 (but there is no mention to it in the function documentation). Time to consider going back to MySQL...

My problem is not with some browsers not showing emojis. My problem is with having a "?" char (0x3F) stored in the database instead of an emoji. Meanwhile I think I was able to trace the source of the issue based on the posts affected. I used a REGEXP_REPLACE query to remove some data from posts, and it seems the REGEXP_REPLACE does not handle some UTF-8 characters properly. Time to try to recover the data from a backup 🙂