Stripe Integration

[Nishit Shan]

#16432

Hello Andrey,

Please check the video for reference:
[video src="https://excellentnumbers.com/temp_vid/Screencast%20from%202026-09-07%2014-38-52.mp4" /]

I have implemented all the registration process changes you mentioned in post #16402, including making the company name optional and adding a processing loader.
I am currently reviewing the remaining tasks in post #16402.

Since I am actively working on this, I will try to complete the Nanotel tasks within the next 2–3 days.

[Andrey]

#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

[Jeff Simpson]

#16438

Hi Andrey, Nishit please find the DB logs attached below:
https://webmaklay.com/slow-query-analysis.md

1. Headline finding
One single query pattern is responsible for 99.0% of all database time.

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

Cheers JF

[Nishit Shan]

#16439

Hello Andrey,

I have fixed all the remaining tasks mentioned in post #16402. Please check the following link for reference:
[video src="https://excellentnumbers.com/temp_vid/Screencast%20from%202026-09-08%2016-04-51.mp4" /]
The 1 you are seeing on the device is nothing to be surprised about. It is basically a serial number, and there is no need to remove it—just something to be aware of.

Regarding the database issue, below are my findings. This is not related to the Bootstrap template integration. As an experienced developer, I am not surprised this issue exists because the technology used in the codebase is outdated, and query building was not as modern as it is today.

The related-products query is slow because:
It checks every product using levenshtein_ratio().
It calculates the same similarity multiple times.
Categories are stored as comma-separated values, so FIND_IN_SET() cannot use indexes.
Phone numbers are being matched as fuzzy product names.
The fallback query may return unrelated products.

The levenshtein_ratio() function is the main cause of the performance issue. To properly resolve this, I will need to create a relational table because categories are currently stored in a comma-separated format. After that, the query will need to be updated accordingly. If you would like me to proceed, please ensure that a backup of the latest database is taken.

Regarding database cleaning, I cannot safely remove data because records may be interlinked, and this is not a small project. However, you can clean data for a specific date range if you are sure it can be deleted.

• This reply was modified 2 weeks, 5 days ago by Nishit Shan.

[Andrey]

#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]

#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 2 weeks, 4 days ago by Andrey.

[Nishit Shan]

#16444

Hello Andrey,
Thanks for the post #16441 .
I’m sorry, I think I did not express my point correctly. When I said I was not surprised, it did not mean I ignored the issue. I was not surprised because, at that time, this was the only or best solution to achieve the goal. Nowadays, queries are handled differently, and query building has become more modern and updated. I did not make this change because it required adding an additional table as a pilot table, and implementing it would have required code and database structural changes. I did not want to disturb your running site or risk any mishap.

Although, I want to clarify that I was aware of that particular function not causing issues. I only realized it was causing issues after the team shared the query.

I will review your other points and get back to you. The above is just my clarification.

[Nishit Shan]

#16445

Hello Andrey,

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 link is not accessible on my site , asking for login on Microsoft . Please provide different public link.

[Andrey]

#16446

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

[Jeff Simpson]

#16451

Hello team, please find more data attached:
https://webmaklay.com/wp-content/uploads/2026/09/pic1.jpg
https://webmaklay.com/wp-content/uploads/2026/09/pick2.jpg

as we found out the Excellent Numbers account slowing down all the server DB please refer to the latest report here:
https://webmaklay.com/slow-query-analysis-2026-09-09.md

we have set the excellent numbers on maintanance and all the issues on the machine have been normalized and all the othre accounts started woring smooth.

https://webmaklay.com/wp-content/uploads/2026/09/maint.jpg

some of the excellent Numbers DB tables are inconsistent and need to work on TYPE and Fix the entire database should use INNODB which is faster

https://webmaklay.com/wp-content/uploads/2026/09/image.png

we have renamed public_html folder to public_html1 for excellentnumbers
that release the database pressurce so database of excellent number and its application bad query is causing issue
once you stop this site, server starts behaving normally

Strongly recomending to enhance excellent numbers DB queries which will normalize entire process!
Cheers JF

[Andrey]

#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]

#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

[Nishit Shan]

#16455

Hello Andrey,

I have seen the report and i will need to review the project’s code and database and this need to create a separate task and assign budget for it . It is not a task can be fix in a ongoing task .

This task will require minimum of 7 days .

• This reply was modified 2 weeks, 4 days ago by Nishit Shan.

[Nishit Shan]

#16457

Hello Andrey,

Please provide a priority order between nanotelecom.us, database query fixes, and the previous registration and other issues you mentioned, so I can proceed accordingly.

[Nishit Shan]

#16458

Hello Andrey,

There is some good news for you!
After using multiple technologies and conducting continuous research for the past 8 hours, I have identified and implemented a solution. Please ask your server team to check it again and share their feedback .

1.
Issue: Every time a customer viewed a single phone number, the server was forced to scan all 594,000+ numbers twice, running a heavy mathematical formula row-by-row. This single feature was taking up to 10 minutes per page view and choking the server.
Fixed: Completely modernized and rewritten the “Similar Numbers” widget. Instead of forcing the database to perform 1.2 million heavy calculations per view, it now uses instant database lookups and calculates matches in computer memory.

2.
Issue:Several large database tables (including product reservations and session tables) had no indexes, forcing the database to scan tens of thousands of rows on basic lookups.
Fixed:Optimized category queries to use direct relationships instead of slow comma-separated text searches.

3.
Issue:Multiple active tables were locking the entire table every time a visitor performed a search or visited a page, queuing up other customers.
Fixed:Prepared clean indexing scripts and converted high-traffic tables to InnoDB (row-level locking), allowing multiple customers to shop simultaneously without waiting.

There is one table that I am unable to handle and convert to InnoDB (cart_product_related_byviews). Please ask the server team to convert it to InnoDB by running the following query:
ALTER TABLE cart_product_related_byviews ENGINE=InnoDB;
Also, please delete data older than 6 months from this table.

[Author]

Posts