[Andrey]

in reply to: Custom Works #16495

Nishit we have set A Record from GoDady to nanotelecom but we can see error page like so can you please check that the links are correct and display proper page?

please try your self to visit portal.nanotelecom.com and see where it redirects
also some more addons to your #16476
https://webmaklay.com/wp-content/uploads/2026/09/voip.jpg
https://webmaklay.com/wp-content/uploads/2026/09/us.jpg

[Andrey]

in reply to: Stripe Integration #16492

Hi Nishit can you please clear this (cart_product_related_byviews) table we have now set it to Innob as system team can not empty tables?

[Andrey]

in reply to: Stripe Integration #16491

Hello Nishit thank you for your video, in addition to #16480, could you please align text and buttons in these areas:
https://webmaklay.com/wp-content/uploads/2026/09/6.jpg
https://webmaklay.com/wp-content/uploads/2026/09/7.jpg
😉

[Andrey]

in reply to: Custom Works #16487

appreciate it Nishit!

[Andrey]

in reply to: Stripe Integration #16486

Hi Nishit can you please send me some screen shots of portout page where were some issues with buttons and fonts, aslo some images of:

“I have completed all the tasks related to the registration, verification, and port-out pages. I’ve also made some design improvements to the port-out page.”

before i reported to EN team all finished 😉

[Andrey]

in reply to: Custom Works #16484

Please check the styles, design and layout everywhere is consistant and proffectional, these gusy will detect “cheep” work immidiately https://webmaklay.com/wp-content/uploads/2026/09/styles.png

[Andrey]

in reply to: Custom Works #16482

Hi Nishit, for start could you please ensue therse three poinst a work perfectly as nanotelcom admin start testing with them:

1.People can easy login / pass recorvery to their portal here
2. Same thing here
3. there is no errors like this here
4. I can see you merge styles but if you open this page the number searching and ordering form is missing on the current sytile please check this out here
5. Please make sure that everything is alligned properly to reduce potencual complains as in here
6. The numbers search and ordering form is working here

So the first impression site works great before diving inside of it, no issues all working , everything alligned, no empty, error pages and so on. If any of the processes take time to proceed such as pass reset, numbers search there should be markers, gif loading, messages “Please wait” for example and so on.

Once these all done we can check inside – i belive all working good there as you said you improved loading speed for it. 🙂

Kind regards Andrey!

[Andrey]

in reply to: Stripe Integration #16480

just noted somthing..
could you please make this font in red square a bit smaller as it is HUGE 🙂
https://webmaklay.com/wp-content/uploads/2026/09/portout.jpg

[Andrey]

in reply to: Stripe Integration #16477

Hello Nishit thank you for your good update!,
will check with EN team and get back to you accorningly,
Yes please Nishit while we waiting for EN team feedback let us also finish nanotelecom, the ssystem team will also finish with domains set up soon.

Kind regadrs Andrey

[Andrey]

in reply to: Stripe Integration #16463

Hello Nishit thank you for updates, i have also good news for you we are happy to add more funds to your EN credit card but EN team would like to check all the points mentioned before gif, notifciation messages and so on fixed and upgraded (related to PortOut Validation buttons stiles font etc)..

Please let me know when you have done EN points so we will check and pay your remaining credit plus extra additional funds for quick DB queries resolutions and upgardes mentioned above.

[Andrey]

in reply to: Stripe Integration #16461

Hello Nishit thank you, for more details it looks that En account has been improved dramaticaly!
Im checking with EN team to add more funds for your work. Please allow me some time i will get back to you on this.

Do you think we can finishe the rest of the poinnts now and continue on Nanotelecom Job?

[Andrey]

in reply to: Stripe Integration #16459

Hello Nishit, sorry for delay with me reply, we have been very bussy here with all these issues coming from everywhere:(

I have read your #16455 and yes please Nishit we must repaire EN DB so could you please send me your plan on the project’s code and database review and repair and most importantly results of this work.

This will help me to negotiate with the EN team about the budget for this work.Aas mentioned earlier there should not be such a work come up for this since we always assure our customers that all the work we do use contemprary encoding tecnnicts which comply with nowaways server security protocols and machine safe perormance.

For your #16458 message – to be honest this your reply was like a music to my ears and it it has been already fixed that would be just a wonderfull result for all of us and espetialy for our customer who will defenately appreciate your input.

So in both cases #16455 and #16458 please confirm if it the DB queries issues have been fixed or you still need some time to finilize these roject’s code and database queries review. The most important out come is proper functioning EN project which wont cause any DB overloads and strees. Once it has been done will check with server team if all works safe and effective will defenately report this matter to the project team admin for some financial acknowledgment.

as per #16457 – surely EN project is under huge stress and this has to be priorotised. Currently server team helping us with nanotelecom setting up so i would recomend to wait for them to finish .com.us A record task which after we can finalise our Nanotelecom.com.us task and start API library jobs preparations.

Till then please Nishit let us make EN project’s code and database improvment then those points as previous registration and other issues mentioned in #16441 m #16402.

Thank you Nishit very much for your quick responds and help!

[Andrey]

in reply to: Messenger App #16454

Hello Dave we have finished investigation on the server and we found that you were right this is issue on the server and this coming from one of the project that Nishit curently working on.

Hoping Nishit will fix it soon and all should be back to normal.
We have tried to disable EN project and found that friends chat started working as usual with no delays and we belive once EN DB issues will be fixed your app will be working as expected.

Thank you for your patance on this, will keep you posted.
Kind regards Andrey

[Andrey]

in reply to: Stripe Integration #16453

Nishit when EN porject works in this conditions it ruins all the accounts iculding webmaklay portal and you can not even access forum and fix the issue, we have now limited DB queries to 30 sec so anything more than that will be killed.

Aslo while you fixing EN DB you can change folder public_html folder to public_html_maintanance so the site not escalating DB qureis and not downing the machine so we must to FIX IT ASAP

[Andrey]

in reply to: Stripe Integration #16452

Yes. It’s one query, and it’s not close.
The query breaking your server:
sql

SELECT p.*, pi.*
FROM cart_products p
LEFT JOIN cart_product_images pi
ON (p.productid = pi.imageprodid AND pi.imageisthumb = 1)
WHERE p.prodvisible = 1
AND productid != 98898
AND FIND_IN_SET(78, prodcatids)
AND prodavailability = ‘unreserved’
AND prodcurrentinv != 0
AND levenshtein_ratio(‘(813) 896-2999’, prodname) > 60
ORDER BY levenshtein_ratio(‘(813) 896-2999’, prodname) DESC
LIMIT 5;

Run by database user excellen_shaz on schema excellen_vip3. It’s the “similar phone numbers” widget on your product detail pages — it fires once per product page view.
What it did on 09-09-2026:

Executions

9,531 of 9,783 in the log
Share of all database time

99.88%
Total time consumed

5,600,935s = 1,556 hours in one day
Rows examined per run

594,007
Rows returned per run

5
Average runtime

588s
Worst single run

6,406s — 1 hour 47 minutes
The worst five executions of the day, all this same query:
Started

Ended

Duration

Thread
06:10:13

07:56:59

107 min

56412
05:30:32

07:16:35

106 min

54410
05:29:42

07:13:55

104 min

54364
05:59:58

07:43:51

104 min

55765
06:52:34

08:31:01

98 min

58620
229 executions ran longer than an hour. 2,096 ran longer than ten minutes. All of them this query.
Why it kills the server specifically:
The levenshtein_ratio() user-defined function has to be computed on every single one of the 594,007 rows — and then a second time for the ORDER BY. That’s roughly 1.2 million UDF calls per execution, each one pure CPU with no index able to skip a single row. FIND_IN_SET(78, prodcatids) guarantees the full scan on its own, since categories are stored as a comma-separated string.
The mechanism that turns a slow query into an outage is the pile-up. Each page view starts a new copy. At peak you had 218 running at once, each burning CPU on 1.2 million function calls. They starve each other, so each one gets slower, so more accumulate. Average concurrency across the whole 24 hours was 65.9 and it never dropped below 19.
Two pieces of evidence confirm the query itself is the cause rather than a victim of general server load:

The isolated manual run by user excellentnumbers — same query, run by hand with far less contention — still took 98 seconds.
Three executions examined zero rows and still averaged 859 seconds. They weren’t doing work; they were queued for CPU that never came. That’s starvation caused by the other copies.

The single fastest thing you can do right now is SET GLOBAL max_statement_time = 30;. It doesn’t fix the query, but it makes it impossible for one to run for 107 minutes, and it would have killed all 229 of the hour-long executions before they could stack up.

[Author]

Posts