[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.

[Andrey]

in reply to: Stripe Integration #16446

Oh sorry about that Nishit, the link in #16445 same document whcih is in #16441 = https://webmaklay.com/slow-query-analysis-new.md
🙂

[Andrey]

in reply to: Stripe Integration #16442

Oh in addtiong to above, Nishit you can rund DB back up from your cPanel access we can only perform full back up which we will do soon for your DB improvments (files atatched)
https://techlyncs-my.sharepoint.com/:t:/r/personal/salman_techlyncs_com/Documents/Attachments/slow-query-analysis-new.md?d=we4c5ea0dac2d4e388893b1dfa89fe8e6&csf=1&web=1&e=ndekB0

• This reply was modified 1 week, 5 days ago by Andrey.

[Andrey]

in reply to: Stripe Integration #16441

Hello Nishit thank you for your reply,
could you please advice what is this 1 serioal number of? could you please remove it we did not have it before and En team do not want to see it there.

i aslo checked your video and can not see you changed buttons and other points mentioned from #16402 below:

1. Down Time task: Yes we will need to updated the coding for those queries to reduce the calls to DB.If you not surpriced then i assume you knew the issue and im now surprised you as exepreieced developer not mentioned that and not updated it as we always ask you to use modern codings and this puts EN proeject under huge risk. So please thoese queries are mentioend in Jeffs report need to be imroved. And as a kindly reminder on ANY tasks we give you we rely on your profecionalism and experience to be able forcast such a truble and risks and implemenet contemporary codings. Now it sounds that we never told you this and we facing this issues builded up by the time:(

P.S System team attached an other document for you with full EN investigation report and possible resolutions to fix it asap. Please find it here.

2. Sand Box: – We can not do anything at this stage really as EN admins did not get back to us about about the time to switch back to Sanbox.

3. Compamy Name as i could see from your video removed from compolsory but if any field missed during regestration does the proper hint displayd (for example ” Phone Number filed is missing “) loading gifs, messages “please wait” and ect? We do not want EN team repeat it again 😉

4. Does all redirects working and centered on the login page? Aslo when email verifications requestsr is everything clear that customers not being confused and do not know that notifications email been sent, and if any processes going behind the sceen customers are aware that processing messages or loading gifs come up. Will the customers know about verification process exeration time and so on?

5. PortOut Validation i could see the process on your video but we still could not see you applied our recomendations about the buttons, allignemnts, font and ect. ( We know that firist time we did not provided such details and you did it as you think is good so no issues with that but now we have got clear instriuctions on changes and thus will add more funds for this task to your EN credit.) Please make this PortOut Validation with better look we know you can:)

6. I noted in your video the popup has now got X close icon, but i aslo noted that when you clicked APPROVE there had been sime time before pop up window actually appeared and there was no any loading gif come up or ” please wait” message apeared. Buttons are still the same and especulay ugl cancell button not been changed:(

It is preety quick process between AProve and pop up but you can see still it takes some time which is DB queries and coding language that we need to do and already mentioned above.

SAMARY

Please Nishit finish all the #16402 points details and please fix the DB/coding issue – those that causing major problems, aftre nanotelecom we will probably get all the DB coddings review and upgarde job – which will need to confirm with EN team as they alwasy belive that during all developemnet we always use new and modern coding technics and this is why they paying for.

[Andrey]

in reply to: Messenger App #16436

Hello Dave, thank you for your message, i have sent system team your video and conserns they are still investigating this matter, i will let you know when they provide more information.Curretnly the invormation i have is not supported by any evedence will give you updates with verified info;)

[Andrey]

in reply to: Stripe Integration #16434

Hello Nishit thank you for your video and removing Company Name from compolsory and fixing these #16402.
Today we have got more complains from EN team they site was down somtime again and we have spoken to system team. They are running more detailed investigation but for now they said that EN cause multiple stresses to the hosting DB.

the main reason for this issue is Long sql queries and queries without index – could you please let me know if you can improve it? The reason for this is that if we can not do it there maybe some other developer will have to have a look at that which we all do not want.

Here are just some examples:
1. Today whet the site was loading very slow we found that the DB got very bussy loading with EN DB queries. So we treid to conect to it many times from desk top or mobile phone but interestengly enough when we open EN from a mobile we’ve suddently seen a login page from OLD mobile version of EN. Since we move the site to responsive we were very surpried that EN opened an old login page from old EN mobile site.

So we started thinking maybe this is the problem when we loading the pages some queires featching old EN mobile version mixed with responsive and this makes the laoding time more dificult and stressed.

2. En other example when we look the EN DB we can see some queries take a VERY long time to connecting and when we checked some tables we cound some of the tables are very heavy please see this here

Could you please advice do we need this table and if so can we drop it and set up a sync script for droping this table if it is over certain level. O was going to drop it myself but i was afraid to do smothing wrong that may harm any of your works. Our system team also suggested to consult with you. Could you please advice ASAP.

I think f we drop this 2.5GB table it will bring some releave for DB too.

So as above we should make EN DB very light and flowing as a fresh wind so people could use EN as they want without stress and down times this is byt the way on of the jobs we should do and reported back that it is not working mentioned in #16402

[Andrey]

in reply to: Custom Works #16430

Hello Nishit got you, thank you for your #16428, well im also not a server guru i will forward your suggestion to the system team to have a look!

How is other things going Nishit when do you think we can show your work to nanotel team?

[Author]

Posts